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Agenda 


Wednesday, February 13th 

8:30-8:45 Plenary: Subgroup Update 



Crystal Springs 


Network Technology Sessions: Crystal Springs 

8:45-9:15 FTS 2000: A NASA Technology Assessment 

J. Klenart/D. Loudon 

9:15-9:45 Muldnet TCP/IP for VAX/VMS 

/. McMahonlL. S. Vance 
9:45-10:15 Break 


Science Networking Keynotes: Crystal Springs 

10:15-10:45 Science Network Resources: Distributed Systems 

N. ClinelJ. Good 

Using HST: From Proposal to Science 
P. Shames 

Galileo Earth Encounter 
T. Clarke 

Question and Answer Period 
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Plenary: Subgroup Update 
Subgroup Meetings 
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Designated Breakout Rooms 
Cypress 


Thursday , February 14th 


8:30-9:30 

9:30-12:00 

12:00 



Plenary: Subgroup Summaries Crystal Springs 

Closing Session Crystal Springs 

Adjourn 
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Editors' Note Updating the Agenda 


For this conference, the Applications Subgroup was merged with the 
User Services Subgroup because Applications Subgroup Chairperson 
Dennis Gallagher was unable to attend the conference. 

The opening plenary session was extended to include a presentation on 
the NREN by Anthony Villasenor. This presentation was given just 
after lunch on Tuesday, February 12, 1991. 

The presentation on MultiNet was delivered by L. Stuart Vance. 

The Science Networking keynotes session was extended to include a 
presentation entitled "Overview of the NASA Astrophysics Data System" 
by R. B. Pomphrey. 
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II. Meeting Summaries 




NSI User Working Group Overview 
Pvonald D. Zwickl/NOAA/SEL 
NSIUWG Chairperson 


The NSI Users Working Group meeting was held at the Bunfey Hotel in San 
Mateo from Tuesday morning until noon on Thursday, February 12-14, 
1991. The meeting was originally scheduled for November 6-8, 1990. It 
was moved to a later date because of the delay in signing the FY91 budget 
into law, and the associated uncertainty in travel for government 
employees. 

Prior to the original (and postponed) meeting, the largest mailings, 
including both electronic and regular US Mail, to date were made. More 
time and effort went into preparing the information packet than past 
meetings, with the initial agenda in place far in advance of the meeting. 

All these efforts offered mixed results. The attendance, for a non-east- 
coast meeting, was larger than any previous meeting, but only by a small 
margin. We had hoped for a larger turn out. Thus, we know a large 
number of people had been reached, yet only a small number of them 
attended the meeting. Is this the sign of success (the network works, so 
why attend); the sign of confusion (just what is the meeting all about); or 
perhaps the lack of money (NSI does not pay expenses to travel to the 
meeting and while it connects users to the network it does not fund them). 

This meeting contained an expanded format compared to previous NSI and 
SPAN Users Meetings. The Executive committee met the day before the 
opening session to review the agenda and discuss any last minute changes. 
At that time a decision was made to merge the User Services with the User 
Applications subgroup, with Neil Cline as the Chair. Dennis Gallagher, Chair 
of the User Applications subgroup was unable to obtain travel funds from 
the group he works with at MSFC. 

The first two days of the meeting contained the usual mix of a project 
overview, informative talks, subgroup discussion periods, and the final 
rap-up plenary session. A new addition at this meeting was the presence 
of Exhibitors. In the past we have had ’special demonstrations', but this 
year we had the first ' attempt at including vendors (see list of exhibitors 
elsewhere). The Exhibit area included several live links to Internet and 
SPAN, which were always busy. 
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The meeting contained the normal lively discussions and the specific 
'findings' from the subgroups. These findings were given during the final 
Plenary session discussion and can be found in the subgroup report 
section. 

This meeting marks the shift of focus of the Users Working Group from a 
heavy emphasizes on network engineering to increasing interest in User 
Services. The general feeling was that future meetings should focus more 
on what NSI could do for the User in the say of on-line services. This is not 
to say that 'networking' is solved, because the network will continue to 
evolve. However, it is time to increase our attention to end Users. 
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Policy Subgroup Summary 
Ron Zwickl/NOAA/SEL 
Policy Subgroup Chairperson 


The NSI Users meeting followed the format of previous meetings with 
subgroups meeting in parallel in the afternoon Tuesday and Wednesday to 
discuss specific interest topics. During the first afternoon, the entire 
discussion period was devoted to understanding today's role for the NSI 
Users Working Group. This was a natural topic to discuss given the 
magnitude of the changes that have taken place within the networking 
project during the last year. The current size of the NSI, its more formal 
way of conducting business, and the assignment of Users Services to 
NASA/GSFC, have produced sufficient interest to re-examine the role of 
users in Todays NSI. The discussion on the second day covered a host of 
other issues. A short summary of the specific "findings" presented to the 
entire Users Group on Thursday morning is given below: 

1. The prime function of the NSI Users Group is information exchange 
between users and the project. 

a. In standard NASA language, the group is not considered an 
advisory group; it is a group than can supply "findings". 

b. It is important that a good working relationship be established 
between the users and the project. The policy subgroup feels 
that there is still room for improvement in this area. 

c. The NSI Office should share their list of concerns/questions 
where user input is wanted/needed. 

d. Users should share their list of concerns/questions where 
project input is wanted/needed. 

2. The Users Group should focus on present and future directions. 

a. Need to help identify future User Requirements. 

b. Are current concerns being addressed? 

3. The Users Working Group is considered the "Grass Roots" level of 
networking related activities. 
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4. There is a need to involve the NASA projects (e,g., ISTP) in the user 

meetings. 

5. It may be useful to change the name from a working group to a User 
Forum . Thus, the group (meeting) could be called the NSI Users 
Forum in place of NSI Users Working Group. 

6. We note that there are certain areas where support provided by the 
NSI Office has been outstanding. Specific examples include: 

a. Conference Support at meetings, such as AGU and AAS 

b. Support for Galileo flyby 

c. Emergency response, such as their ability to bring LMSO back 
up after the 1989 Earthquake in Palo Alto 

7. The users felt that existing networks should be used, if appropriate, 
to meet user requirements. 

8. It is important to continue to find ways to reach out to NASA 
sponsored scientists. Good example include the very useful mail 
matrix and NSI support at major conferences, such as AGU. 

9. The users were unable to determine the process within the NSI 
Office for evaluating and responding to User Group "findings". 

10. The NSI Office should continue to support multi-protocols, including 
TCP/IP, DECNET I V/V, and OSI. 

11. To help users focus their discussion during annual meetings, a 
minimum level of information in several areas, including budgetary 
should be presented during the project overview. Detailed, line by 
line items are specifically not requested. 

12. We recommend that each subgroup have a Chairperson and a Vice- 
Chairperson. The Chairperson would be a user, while the Vice- 
Chairperson would be from the NSI Office. This would promote 
better User/NSI interaction during annual meetings. 

13. All User Group Chairpersons would have limited terms of two or 

three years. 
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Network Subgroup Summary 
Linda Porter/NASA/MSFC 
Network Subgroup Chairperson 


The Network Subgroup contained anywhere from 10 to 30 members at this 
meeting. Topics of discussion included: re-engineering of the NSI-DECnet 

backbone, interoperability of PSCNI and NSI-TCP/IP, and tail site 
bandwidth upgrade for sites connected with 9.6 Kbps services. The most 
time was spent discussing DECnet OSI/Phase V transition topics. 

Phase 1 of the re-engineering of the NSI-DECnet backbone will increase 
available bandwidth from 56 Kbps up to 728 Kbps between the ARC, JPL, 
and the GSFC field centers. ARC-JPL leg will be 448 Kbps, the ARC-GSFC leg 
will be 392 Kbps, and JPL-GSFC leg will be 728 Kbps. The actual upgrade 
will entail moving the NSI-DECnet (SPAN)) backbone, which has always 
used DEC routers, to the NSI-TCP/IP backbone, which uses routers capable 
of supporting both TCP/IP and DECnet (creating an NSI multiprotocol 
backbone). The routers currently in use are manufactured by Proteon, Inc. 
The issues of this re-engineering centered on how the ability of the users 
(usually the tail site technical contacts, rather than the scientist) to trace 
routes through the network transparently, will no longer be possible, since 
the existing multi-protocol routers do not support a read-only access mode 
or other method to supply DECnet information. There were several notes 
in this discussion. Proteon is currently developing software to allow a 
form of network access that dumps details of DECnet routing information, 
which was estimated to be due for release in eight months or so. Before 
this software upgrade is available, however, it will not be possible to trace 
routes through the network for DECnet. The routers will be "black boxes" 
in the network to the user. The only temporary work-around will be for 
maps if the network is to be made available to the users so that they may 
manually trace route segments. In addition, the Routing Center (RC) 
managers will be able to trace paths through these routers if there is a 
problem. The user may call his RC or the NOC for assistance, if necessary. 

Finding 1: NSIO is asked to provide an on-line map of the 
network containing sufficient DECnet information for users 
to be able to trace routes on both sides on the multiprotocol 
routers. It's suggested the map contain DECnet and IP address 
information, be in postscript format and made available on 
the NSIPO system and the NSI NIC. 
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Finding 2: The subgroup asks that the NSIO either develop 

or acquire software to allow users to trace DECnet routes, 
and to notify the users when this software is available. If 
this includes a special program, the NSIO is asked to place the 
program(s) on the NIC and/or NSIPO systems. 

2. Next on the discussion list was a review of tail site upgrades 
provided by Mark Leon during the preliminary session. The 
question of who buys the routers (when such are needed) was asked. 
NSIO representatives present indicated the policy is that the NSIO 
supplies the routers at no cost to the tail site when such are needed. 

3. The "HEP-SPAN" interconnect architecture was described by Milo 
Medin of the NSIO. This T1 interconnect is supplied by the Federal 
Interconnect exchange point on the West coast (FIX-W). 

4. There was some confusion regarding NSIO directions with respect 
to OSI transition as presented in the Network Management Retreat 
results talk. The discussion can be summarized as follows: 

The network subgroup would like to see a clarification of the 
relationship of the vision statement: "Achieve a single 

homogeneous network over 3-5 years based on OSI" and the 
statement that the NSI Project will make "....use of Internet, 
interim NREN and NREN..." resources to satisfy network 
requirements. 

And, noting the emphasis on the growing use of non-NASA networks 
rather than dedicated circuits for network requirements: 

Finding 3: The NSI Office should not lose the ability to 
install private, dedicated circuits when justified by NASA 
science requirements. 

5. The status of the progress of NSI-IP to PSCNI-IP interoperability 
(for Space Station user communication to NSI-IP users) was noted 
as not having changed from last year. The primary impediment has 
been the "access controlled" (i.e., closed) PSCNI backbone 
implementation. The PSCN representative present then briefly 
outlined the PSCN proposal to open the PSCNI backbone (remove the 
access controls), thereby allowing the two networks to 
communicate. There are other issues that require further discussion, 
and an engineering meeting has been scheduled to take place 
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in early March between NSI and PSCN engineers. 

Finding 4: As we said last year, NSI and PSCN engineers must 

pursue and solve interoperability issues between the NSI and 
PSCN backbones so Space Station and NSI-IP users can 
communicate. 

6. Day 2 started with an overview of Phase V/OSI transition. A 
summary of the discussion following the talk follows: 

The transition to OSI/Phase V should be separated from the 
issues of pure OSI transition. 

The NSI Office must support active planning for Phase V/OSI 
and the transition. 

User sites are looking to the NSI Office for guidelines and 
coordination. 

Finding 5: Recommend the NSIO assign a team to actively 

coordinate Phase V transition planning with NSI-DECnet 
backbone and user sites. 

Some mechanisms for achieving this were discussed. 

Inter-center Coordination: The Inter-center Committee for Computer 

Networking (ICCN) should form a working subgroup to address Phase V 
transition issues. Participation of the NSI-DECnet RC managers is proposed. 

User Site Coordination: A mail list of the participants at the meeting was 

generated. RC site managers lists should be appended to this list. Also, a 
Usenet bulletin board feed will be set up. Users will be notified by mail 
how to access the bulletin board. 
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Security Subgroup Summary 
Ron Tencati/STX 
Security Subgroup Chairperson 


This year's turnout at the Security Working Group was very low. This 
would seem to indicate that when there are no security incidents present, 
concern about security on the network wanes. However, the security of 
the network is heavily dependent on the participation of the node mangers 
and organization security contacts. 

Over the past year, NSI has become involved in many security-related 
projects with the NASA AIS Program Office. Since very few people 
attended the working group session, I'll outline the work that is being done 
in the Security arena, since much of it will affect end-users of NSI: 

1 . Risk Analysis and Management 

In December of 1989, the GAO produced a report that was critical of 
the lack of a Risk Analysis of NSI's two major networks. All NSI sites 
are required to perform a Risk Assessment with the Computer 
Security Act of 1987. NSI will be working with NIST and Code NTD 
this fiscal year to produce Network and Tail-Site Risk Analysis and 
Management guidelines. 

2. Security Toolkit Software 

As time and operating systems progress, the VMS ("SPAN”) Security 
Toolkit becomes increasingly outdated. Through Code NTD, NSI is 
currently engaged in a survey of Security Toolkit software, and will 
be making available to the user community both UNIX and VMS 
toolkit software in FY91. 

Doug Mansur from Lawrence Livermore National Labs brought two of 
his group members to our working group meeting. They presented 
an overview of LLNL's "SPI" (Security Profile Inspector) software 
that they are developing under a DOE contract. LLNL’s toolkit 
software currently runs on VMS and UNIX platforms. There was 
discussion of merging the NASA and DOE efforts together. 
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3. Security Policies and Procedures 

A new NSI Security Policy Document is being written. It is being 
targetted for release in FY91. This document will more clearly define 
the roles and responsibilities of a remote site security manager, and 
will also state the official security policy and incident reporting 
procedures for systems comprising the NSI. This document will 
supercede the existing SPAN Security document, and will address 
security requirements on both VMS and UNIX NSI nodes. 

4. NASA Computer Emergency Response Team (NASA-CERT) 

NSI is working with NASA AIS Program Manager to develop an 
incident reporting and handling capability for NASA. NSI has been 
assigned a lead role in this effort, and is currently a participant in 
an international, multiagency effort called "CERT System", sponsored 
by NIST. This group first came into being as a result of the WANK 
Worm attacks on DECnet in 1988. 
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User Services and Applications Subgroup Summary 
Neal Cline/UCLA/IGPP 
User Services Subgroup Chairperson 
Acting Applications Subgroup Chairperson 


1. Network Requirements Processing 

The task of gathering, documenting, and consolidating requirements 
for NSI connections is now being very effectively handled by the 
NSIPO. The staff and management deserve congratulations for this 
success. No problems were reported. 

There is a Customer Service Representative (CSR) for each discipline 
area, and network users are encouraged to make contact with their 
CSR to establish requirements or obtain information. This system 
was found to be working well. 

2. User Help Desk 

The plans for implementation of network users' support services, 
presented by Lenore Jackson of GSFC were found to be adequate for 
users' needs. No evident deficiencies were noted. 

Telephone and e-mail contacts for "one-stop" support from the 
NSI User Support Office were publicized, (see slide) 

The ability of the NSI to deliver 24 hr. 7 day support for network 
connectivity was questioned. In particular it was found that the 
DECnet routing center at JSC did not normally have support outside 
at prime shift. 

3. On-Line Services 
a. The NSI NIC 

The NSI User Services Office introduced a menu-driven Network 
Information Center (NIC) implemented by Brian Lev at GSFC, who 
deserves congratulations for this contribution. 

This NIC is expected to satisfy the needs of users of both TCP/IP 
and DECnet protocols. It will not be necessary to have more than 
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one NIC, except to provide backup (redundancy). 

The User Services Office needs input from the users concerning the 

contents of the new NIC. 

b. USENet News Service 

It was found that providing a USENet feed for NASA users would be 
an appropriate service to be provided by the NSI User Services 

Office. 

An NSI newsgroup is recommended as an additional way to 
disseminate information about NSI services and activities. 

c. "white pages" 

A prototype X.500 directory services implementation is already in 
operation at many internet sites and in particular at some NASA 
centers. It was found that NSIPO involvement is desirable, and that 
the User Services Office should be actively involved in this key 
development. 

4 . Conference Support 

The NSI provides network access and associated services at selected 
science conferences. This service is very important to NASA 

scientists. 

NSI's plans and schedule for future conferences need to be made 
known to the science community. 

Scientists need to know how to make their requirements for future 
conferences known to NSI. It was found that at present this is done ' 
by communication with division chiefs at NASA Headquarters and 
with the NSI Customer Service Representatives (CSRs). 

Excessively costly services at some events may preclude support at 
others which are needed also. NSIPO attention to costs at each event 
is needed to insure equitable coverage. 

5 . Applications 

NETWORK applications software should be made available in the NSI 
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NIC. An example is data compression, which improves network file 
transfer efficiency. 

Application standards should have visibility in the NSI NIC. On the 
other hand it was found that the establishment or promotion of 
specific application standards is not an appropriate function of the 
NSI. 
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III. Presentation Material 
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A Opening Session Remarks 
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NASA SCIENCE INTERNET 
USERS WORKING GROUP 
OPENING SESSION REMARKS 
Ron Zwickl, Chairman 


Welcome 


• Yearly Meeting 

• Key People 


• Subgroup Chairs 

Linda Porter 
Neal Cline 
Ron Zwickl 
Ron Tencati 

• Fred Rounds - 


Networking 
User Services 
Policy 
Security 

NSIO 


Project Manager, NSI 


• Susan Aaron - NSIO 

NSI Conference Coordinator 


• Lenore Jackson _ NSIO 
NSI Proceedings Coordinator 


PRECEDING PAGE 
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INTRODUCTION 


What Are We? 

- Users Group 

Represent "All Walks Of Life" 
(Within OSSA) 

Why Are We Here? 

Information Exchange 

* With Each Other 

• With NSI 

Voice User Concerns/Issues 

Why Are There Subgroups? 

Allows Full Discussion 
Covers Different Interests 
Change With Time 
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HISTORY 


"Communicate And Increase Productivity For Scientists" 

1 980 • "Needs" 

• Scan 

• SPAN 

1985 s First Project Use 

• Ice Comet Encounter 

• NSN 

1988 * NSIPO 

1990 • Management Retreats - Overview by Jim Hart, NSI 
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MEETING GOALS 


- Discuss Today's issues 

- As Seen By Users 

- Information Exchange 

- With NSI 

- With Each Other 

- Forward Concerns To NSI 

• Publish Proceedings 
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B. NSI Project Presentations 
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NSIUWG 

Science Networking Retreat 


Jim Hart 

Assistant Chief, Information and Communications Systems Division 

February 12, 1991 




Overview 


Sponsor: 

Ray Arnold, Chief, Code SC Headquarters 

Purpose: 

Study, Identify Alternatives, Recommend for Science Networking 
Vision, 

Roles and Responsibilities, and 
Technical Approach and Transition 

Retreat dates: 

June 7, 1990 
July 30, 1990 

Implementation Status: 

Draft "White Paper" being prepared 

Management and technical implementation in progress 



P g ■ ^ m 

articipants 


Dr. Robert Price 

Tony Villasenor 
Jim Hart 
Dr. Jim Green 
Sandy Bates 
Rick Helmick 


Deputy, Earth Sciences Directorate (900), GSFC 

Program Mgmt, Science Networks, Headquarters SCI 
Manager, NSI, Ames (ED) 

Manager, NSSDC, GSFC (930) 

Program Mgmt, Headquarters PSCN (OS) 

MSFC, PSCN (Al) 


Ray Arnold, Joe Bredekamp: Management support as needed 



Vision 


Science Networking is End-to-End service under OSSA management. 

OSSA direct efforts to achieve single homogeneous network over 3-5 
years, based on OSI. 


Cooperate with other agency efforts to achieve single agency-wide 
network over 8-10 years. (Create Inter-Center Coordinating Comm) 


Upgrade current science network to basic service offering of 56kbps 
tails and T1 backbone circuits. 


Provide service for both Science Data Operations (Mission Essential 
and Mission Success) as well as general research and analysis 
communities. 












SCIENCE NETWORK 


ROLES AND RESPONSIBILITIES ■ 

- HQ OFFICES 

oso 

OSSA 

OVERALL MANAGEMENT OF NETWORKING 
FOR AGENCY 

• MANAGEMENT OF SCIENCE 
NETWORKING 

INSTALLATION AND MAINTENANCE OF 
ENTIRE AGENCY BACKBONE 

* SCIENCE USER REQUIREMENTS 
ASSEMBLY AND ANALYSIS 

OVERALL NETWORK ENGINEERING 

•SCIENCE NETWORK 
ENGINEERING AND 
OPERATIONS 

INTERFACE TO INTERNATIONAL AGENCY NETWORKS 

• INTERFACE TO INTERNATIONAL 
SCIENCE NETWORKS AND U.S. 
NON-NASA NETWORKS 


USER SERVICES AND 
APPLICATIONS DEVELOPMENT 


SCIENCE NETWORK 


ROLES AND RESPONSIBILITIES - CENTERS 


ARC 

GSFC 

MSFC 

NSI MANAGEMENT 

• USER SUPPORT SERVICES 

• PSCN MANAGEMENT 

NSI ENGINEERING 

• APPLICATIONS DEV 

• AGENCY BACKBONE 
ENGINEERING 

NSI OPERATIONS 


• PSCN OPERATIONS 

CONNECTIVITY TO 
INTERNATIONAL SCIENCE 
NETWORKS 


•CONNECTIVITY TO 
INTERNATIONAL AGENCY 
NETWORKS 

CONNECTIVITY TO NSF, 
NREN, AND UNIVERSITY 
NETWORKS 


•CONNECTIVITY TO 
CONTRACTOR NETWORKS 
AND NON-SCIENCE 


ACTIVITIES 


Assignment 

Summary 

for 

Science Networking 


Function 

Now 

Prop 

0.0 Program Management 

HQ 

HQ 

1 .0 Project Management 

ARC 

ARC 

2.0 Network Engineering 

ARC, GSFC 

ARC 

3.0 Network Operations 

ARC, GSFC+ 

ARC 


2.0 Network Engineering 

3.0 Network Operations 




0.0 NSIP0 PROGRAM MANAGEMENT 


PROVIDES OVERALL PROGRAM MANAGEMENT AND 
ADMINISTRATION OF OSSA SCIENCE NETWORKING OBJECTIVES 

AND GOALS 


0.1 PROGRAM MANAGEMENT 
POLICYPLANNING 

USAGE, ETHICS, SECURITY 
STRATEGIC AND ADVANCED PLANNING 
OS1 and NREM 

Program Reviews (regularly scheduled) 
Program Plan 

0.3 External Interfaces 

NASA: Code O, R, Centers 

Other WHEN agencies: NSF, DOE, DARPA 

National 

International 


i .o nsipq m m •• / mm and administration 

{Assignee! to ARC} 

PROVIDES OVERALL PROJECT MANAGEMENT AMD ADMINISTRATION 
OF OSSA SCIENCE NETWORKING OBJECTIVES AND GOALS 

1.0 Project Management 

SSC 5 User Group, end ICC 1/ 

BUDGETING AND ACCOUNTING 

SCHEDULING 
PROCUREMENT 
PERSONNEL PLANNING 
FACILITIES DEVELOPMENT 

1.1 USER REQUIREMENTS MANAGEMENT 
Requirements gathering and validation (NSR Process) 

MGU develoraiTient 

Tracking & Statusing 

1.2 SECURITY MANAGEMENT 
Risk analysis 
Incident Investigations 
External coordination 

1 »3 External Relations 
PSCN 

— National & International 



Assigned to ARC 

2.1 Requirements Swppcjrf 

Requirements cSatabasing 
Requirements consolidation 

2.2 General network engineering 

2.2.1 NETWORK ARCHITECTURE/CO ^FIGURATiON 
Overall architecture 

Technical i/f mih external architectures 
22.2. DECNET & IP ENGINEERiMG V/ORKSMG GROUPS 
Design of logical networks (P V conversion} 
Parameters and addressing 
Configuration Documentation 

2.2.3 SERVICE NSTALLATIOM and TESTING 

Network service acquisition, testing, checkout 

2.2.4 SECURITY 

Development & implementation of security measures 
Development of network security tools 

2.2.5 PSCM 1/F Representative 

2.2.6 TESTBED ACTIVITIES 
OSi Planning 

Advanced network technologies 

2.3 NREN SUPPORT 

2.3.1 High Performance >tetwork Te ch nologies 



3.0 OPERATIONS 


Assigned to 
ARC 
GSFC 

3.1 NETWORK OPERATIONS (ARC) 

7-DAY, 24-HOUR NETWORK OPERATIONS CENTER (NOC) 

NETWORK MONITORING AMD TRAFFIC ANALYSIS 

PROBLEM MANAGEMENT; Reporting, Repair, Maintenance Service 

FLIGHT PROJECTS AMD MISSIONS NETWORK SUPPORT 

UPDATES AND MAINTENANCE 

PROPERTY AND INVENTORY MANAGEMENT 

Interface With Remote Site Local Area Networks and Management 

ROUTER HW/SW MAINTENANCE CONTRACTS AND LOGISTICS 

OFF SHIFT SUPPORT FOR NIC 

Security Monitoring, Verification, Auditing 




User Help Desk & HOTLINE (WITH NOC) 

User Information Forums 

NSI User Working Group Coordination & Logistics Support 
Conference Support 
Regional Customer Support 
User Security 

inform end users on security policies and plans 
Distribute "kits” and other security material to all users 
Online Requirements Status Lookup 



5.0 NETWORK APPLICATIONS DEVELOPMENT 

( Assigned to GSFC) 


5.1 Application Development 

INTEGRATION OF CODE SC INFORMATION SYSTEMS IN NETWORKING 
interoperability Gateways 
Applications Utilities 

Distributed Applications Development and Support 

Applications Demonstrations 

Development ©f Host Security Software Tools 


h *** HR© 
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Technica 


ransition Plan 


Science Networking to Maintain End-to-End Service Responsibility 


Convert DECnet Phase IV Science Traffic From 56KBPS "SPAN" Backbone to 
NSI Backbone. Initially at Fractional T1; Upgrade to FULL T1 


Convert All Tail Circuits to Multi-Protocol Capability at Minimum of 56kbps 
Support IP, Phase IV and Phase V When Available 
Replace Single Protocol Equipment With Multi»Protocol or Equivalent 


Reduce Over Time the Number of NASA-Owned (PSCN) Tail Circuits Through 
Use of Internet, interim NREN, and NREN Except for Certain Mission 
Essential Requirements 


Connect NREN to Science Centers and Utilize National Backbone Infrastructure 
for Primary Routing of Science Traffic 




Science' 


Explore and Determine Feasibility of Utilizing Expanded Code OS (PSCW) 
Services for Science Traffic (Phase V and/or IP) on PSCN Backbone. 

If Technically Feasible, 

Define "Contract" Relationship With PSCN to Preserve OSSA End-to-End 
Science Services 

Define and Test Using Segment Prototype Demonstrations 
Phase V ©n PSCNI Backbone (Using Science Phase ¥ Tails) 

IP on PSCNI Backbone 
Expand as Desired 

Migrate to Vision 


Technical Meeting: March 4, 1991, Dallas TX 



Agency-Wide ResponsibiOities 
Protocol Address Space 


Address Space Agency Coordination 

DECnet Phase IV NSI 

Inch SSF, etc. (Area 48 With Representation on NSI DECnet Eng. Group 
PSCN Responsible for End-to-End Service for Their Requirements 


IP MSI 

e.g., . . .NASA.GOV and . . PSCNI.NASA.GOV 

NSI and PSCN Responsible for End-to-End Service for Their Requirements 

OSi (e.g., Phase V) PSCN 

TBD 

NSI and PSCN Responsible for End-to-End Service for Their Requirements 


On 

NO 




NASA Science internet Users Working Group 


February 12, 1991 
San Francisco, California 


CD 


i - 

JO ; 


Information & Communication Systems Division 

AMES RESEARCH CENTER 



Agenda 



NSI Organization and Highlights - Fred Rounds 
Customer Requirements Process - Yvonne Russell 
Engineering Review - Mark Leon 
User Services - Pat Gary 
Security - Ron Tencati 

Backbone Upgrades and DEC Equipment Replacement - Warren Van Camp 



tion 


Intercenter Coordinating 
Committee for Science 
Networking 

ICC/SN 



Network ! 


Architecture 


(Medin, TCP/IP 


Van Camp, DECnet) 









NSi Highlights 

Administration 

NSI is fully funded by Code S 
Project staffing increased 30% 

Code S reorganization in process 
Enginee ring 

Backbone upgrades planned to serve both DECnet and TCP are in final 
review 

Planning underway to make use of National Research and Education 
Network 

NSI involved in planning for EOS networking 
Operations 

NSI providing 24X7 operations in new Integrated Network Operations 
Center 




NASA SCIENCE INTERNET 


Presentation to 

MSI USERS WORKING GROUP 
February 12, 1991 


Yvonne Russell/Chrisfine M. Falsetti 
Customer Service Manager 
NASA Science Internet 
AMES RESEARCH CENTER 
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Network Engineering 

• Requirements analysis and optimization 

♦ Network design and configuration 


Operations 

* Maintains 24x7 network monitoring 

* Trouble call resolution and tracking 

^ Reliability and performance validation 


Coordinate Integration of Info. Systems 
Integrate Advanced Applications 
Implement Network Information' Services 


NASA Science Internet 










Project Planning Process 


NASA SCIENCE INTERNET 


HQ PROGRAM 
VALIDATION 


OSSA 

PROGRAM 

MANAGEMENT 




Setencs 


rograms/Projects Active!; 
Supportei 


Space Life Sciences 1-4 

Cosmos 

IML-1 

Spacelab J 

liMjsSfiMweanciADDiicaiiQns (SE) 

Earth Radiation Budget Exposure (ERBE) 
Upper Atmospheric Research (UARS)‘ 
Ocean Topography (TOPEX) 

Earth Observing System(EOS) 

Crustal Dynamics ** 

WETNET 


Solar System Exploration (SU 
Voyager 
Magellan 
Galileo * 

Mars Observed* 
CRAF/Casslnl* 

Pioneer 

Shuttle Flight-Engineering (SM) 

High Resolution Solar Observer 

Mjcrogravity Science (SN) 

International Microgravity 


Space Physics (SSI 
CRRES 

Dynamics Explorer 
Solar A 
Ulysses 

International Solar Terrestrial 
Physics 

MlrjapiLV5jcp.(SZ! 

Cosmic Background Explorer 

Gamma Ray Observatory 

Hubble Space Telescope 

Kuiper Airborne Observatory 

Stratospheric Observatory for 
Infrared Astronomy 

Space infrared Telescope Facility 


| i 

| 

if 


MOU In progress 
‘MOU complete 

““MOU nearing slgnoff completion 


NASA Science Internet 
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NASA Science Internet User Working Group 



NSI Engineering Review 
February 12, 1991 


Mark Leon 

Engineering Manager 

NASA Science Internet 

Information & Communication Systems Division 
AMES RESEARCH CENTER 


aiASA 




NASA Science Internet 
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New Connections 








Tail Site 

Hub Site 

Bandwidth Path 

National Geodetic Survey, MO 

GSFC 

56 Kb/s 

Terr. 

Scientific & Technical Information Facility, MD 

GSFC 

56Kb/s 

Terr. 

Ford Aerospace, MD 

GSFC 

56 Kb/s 

Terr. 

University South Florida, FL 

KSC 

56Kb/s 

Terr. 

Gilmore Creek Geophysical Observatory, AK 

ARC 

56 Kb/s 

Sat. 

University Alaska Geophysical Institute, AK 

GCGO 

56Kb/s 

Terr. 

Cerro Tololo Inter-American Observatory, Chile 

MSFC 

56Kb/s 

Sat. 

Big Bear Solar Observatory, CA 

ARC 

56Kb/s 

Terr. 

STX, MD 

GSFC 

T1 

Terr. 

Rice University, TX 

JSC 

T1 

Terr. 

University Montana 

ARC 

9.6Kb/s 

Terr. 

World Weather Building, MD 

GSFC 

56 Kb/s 

Terr. 

Space Telescope Science Institute, MD 

GSFC 

T1 

Terr 

Carnegie Institute of Washington, DC 

GSFC 

9.6Kb/s 

Terr. 

United States Geological Survey, Az 

JPL 

56Kb/s 

Terr. 

Ellery Systems Incorporated, CO 

NCAR 

56Kb/s 

Terr. 


NASA Science Internet 
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NASA Science Internet 






Upgrades Scheduled for 1991 


GSFG-Brown Univ. (*) 
GSFG-Corneil Univ. (P A 56) 
GSFC-NASA HQ (*DP56) 
GSFC-ST Systems (*T1) 
GSFC-Unfv H MD (*ET1) 
GSFC-Carnegie Mellon (U) 
GSFC-MRL (P A ) 


GSFC-Penn. St. (P A 56) 
GSFG-NRAO (U) 

MSFC-Utah St. (U) 
MSFC-Univ. Minn. (P A 56) 
MSFC-Univ. Chicago (P A 56) 
MSFG-LSU (PR56) 

* = Complete 
P = In Progress 
DP = Dual Protocol 
T1 = 1.544Mb/s 
U = Under Review 


JPL-NPGS (P A 56) 
JPL-Unlv. Arizona (PRT1) 
JPL-USGS, Flagstaff (*56) 
JPL-Aerospace Corp. (U) 
JPL-NOAO, Az. (*56) 
JPL-PSl, Az. (P) 
ARC-ISAS, Japan (PR56) 
JSC-Univ. Colorado (P) 
JSC-LANl (U) 

JSC-NCAR (P) 

JSC-SWRI (U) 

JSC-Rice Univ. (U) 


A = Circuit upgrade planned 
E = DECnet Encapsulation 
R = Request for service issued 
56 = 56Kb/s 
( ) = Status 


GSFC-Univ.Rhode Island (P A 56) 


NASA Science Internet 
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Upgrades Scheduled for 1992 & 1993 



Upgrades for 1882 
GSFC- Univ. Delaware 
GSFOUniw. Maw Hampshire 
GSFOWHQig Mass. 
GSFC-Yale University 
MSFC-USRA, Ala. 
MSFC^Univ. Wisconsin 
MSFG-Washington Univ. 
JPL-RAND Corp., GA 
MSFC-EROS at USG8, SD 




U pgrades for 1983 
GSFG-Dartmouth Univ., N.H. 
GSFC-Grumman, NX 
GSFC-MIT, Mass. 

GSFC-NRG, Canada 
GSFC-NOAA/WDC 
GSFC-USGS, Reston 
GSFC-Univ. of Delaware, Lewes 
MSFC-Augsburg College, Minn. 
MSFG-Florsda St. Univ. 
SVISFC-Univ. of Kansas 
MSFC-Unlv. of Mich. 
JPL-Oregon St Univ. 


NASA Science Internet 
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NS1 Dual Proto 

Reference: NSI Use 
February ‘ 

Warren Va 


page 





Si Dual Protocol Backbone 


Upgrade DECnet links to match TCP/IP links performance 

Integrate backbone resources and central management 

Transition to be done In two phases 
9 Phase 1 - "top triangle" GSFC, JPL, ARC 
9 Phase 2 JSC, MSFC, KSC 

Phase 1 transition plan developed 
* Warren Van Camp, Jeffrey Burgan, Linda Porter 


page 2 




NSI Dual Protocol Backbone 



ase 1 transition process 
Perform necessary reconfigurations 

Turn on DECnet routing on NSI Proteon routers as backup path 

Change circuit cost for ARC- J PL to use dual protocol as primary 

Change circuit cost for ARC-GSFC and JPL-GSFC to use dual 
protocol path as primary 


Monitor and evaluate performance 

J 
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NSI Dual Protocol Backbone 


Backbone network operations 

• NSI operations - 24 hours/day, 7 days/week, engineers on call 


DECnet routing equipment 

• NSI is replacing existing DECnet-only routers to provide multiple 
protocols to tail sites and manage network from 24x7 NOC 

• Use of existing DECnet dedicated routers may be maintained where 
only requirement Is for DECnet 



NASA Science Internet (NSI) 

User Support Services and Network Application Development 


oo 

VO 


J. Patrick Gary 

Advanced Data Flow Technology Office 

Code 930.4 

Goddard Space Flight Center ^ 

CD 


Presentation to 

NASA Science Internet User Working Group 
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February 12, 1991 


NSi User Support services and Network Application Development 

- An Overview - 

Outline 

• Background 

VO 

O 

• Elements of MSI with GSFC Responsibility 

• GSFC Element Objectives 

• Summary of Current Status and Plans 



NSI User Support Services and Network Applications Development 


Background 


• At the Network Management Retreat meetings of June and July 1990, key network 
managers representing Headquarters Codes O and S and the Centers ARC, GSFC, 
and MSFC concurred on a vision of the future of NASA's science networking and 
developed major new agreements in regard to the Centers' roles and 
responsibilities in science networking, including: 


ARC 


GSFC 

User Support Services 

Network Applications Development 


NSI Management 
NSI Engineering 
NSI Operations 


NS1 User Support Services and Network Applications Development 


Background 

• On September 27, 1990 the first public announcement and open discussion on the 

new agreements was made at the NSI Science Steering Committee meeting (The 
White Paper further describing the agreements, on which prior discussion had 
waited by management request, is not yet available) 

• On October 17, 1990 NSI's Project Manager F. Rounds concurred with the package 
of GSFC's NSI Work Breakdown Structure (WBS) responsibilities prepared by 
GSFC's P. Gary. 

• On November 7, 1990 F. Rounds forwarded memo to P. Gary to implement NSI 
program at GSFC. 



NSI User Support Services and Network Application Development 


Elements of NSI with GSFC Responsibilities 

• User Support Services (GSFC Lead) 

- Network User Help Desk 

- On-Line Services Baseline 

- User Conference Support 

• Network Applications Development (GSFC Lead) 

- Requirements Definition and Analysis 

- New Core Developments 

- Exploratory Developments 

• Additional Tasks Supporting Areas with ARC Lead Responsibility 

- User Requirements, Security, Network Engineering, Network Operations 


NSi User Support Services 

Network User Help Desk 


• First stop for all user questions/problems 


• Minimally 12 hours/day, 5 days/week coverage with off-shift support from NOC 


• Accessible via phone (301-286-7251, 1-800-NSI-HELP), fax (301-286-5152) and 
e-mail (NSIHELP@NSINIC) 


• Provides assistance in effective use of both DECnet and IP protocol suites 

- Network configuration guidelines for user host systems 

- User guides e.g. e-mail syntax matrix and interoperability gateway usage 
procedures 


• Provides assistance in network user problem diagnosis with on-line 

access to real-time NSI network status data, NSR and NIC data bases, and trouble 
shooting tools 


(1) Have planned to extend coverage to 24 hours/day, 7 days/week by FY93 

(2) Support for the OSI suite has also been initiated, presently is very limited, but will 

increase as OSI becomes more used 



NSI User Support Services 
On-line Services Baseline 

» Information Servers, e.g., interactive NIC's and Anonymous FTP 

- NS! User Guides addressing systems configuration guidelines and 
usage procedures for effective network use 

- NSI bulletin board and on-line newsletter 

- NSS circuit usage and performance statistics 

- Updated network applications software, e.g., latest release of XII windows 

- White and Yellow Page directories 

* USENet News Server: general community bulletin board/"conferencing" system 

* Interoperability Gateways for e-mail, file transfer, and remote loaon amona 
DECnet TCP/IP, OSI, BITNET, X.25 

* Remote Node Access Servers, such as NICOLAS and ALEX, to Master Directory, 
GSFCMaii/NASAMail and various Internet/OSSA system resou rces 


Mail Servers for distributing notices to specific user groups 



NSI Network Information Center (NSINIC) Version 1.0 System 


F i rat TELNET DFTNIC.GSFC. NfiSfi , GOU (128.183.10,3) or SET HOST DFTNIC (6116), 

then enter username NSINIC 


\o 
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NSINIC TOP HENU 


HOU TO USE THIS SVSTEH 

Info About the NSI and Other Nets 

NSI Personnel for Additional Help 

HELP FILES AND INFO 

Connect to SPAN_NIC 

Connect to NICOLAS 

Report A Problem 



HELP FILES AND INFO 


E-Na i I Syntax Hat r i x 

The EAST Interoperability Gateway 

How t o Trans fer Flies 



The ERST Interoperability Gateway 


The NASA Science Internet Project Office 
(NSIPO) has funded an Interoperability 
Gateway to facilitate the exchange of 
E-Hall, file transfer and remote logon 
capability between TCP/IP-based networks 
and DECNet-based networks. 

The Interoperability Gateway at Goddard 
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NSI User Support Services 


On-Line Services Baseline ( Continued ) - Notes on Current Status 


(1) NSI Network Information Center (NSINIC) Version 1.0 in beta release 
■ Information about the NSI and other networks 

- On-Line User Guides, e.g. E-mail Syntax Matrix and EAST interoperability 
Gateway (EIG) 

- Who to call for additional help 

- Auto-Logons to SPAN-NIC (contains SPAN Yellow Pages) and NICOLAS 

- Report problem/request help 

Anonymous FTP File Server already hosts over 200 Unix, VMS, and Macintosh 
programs 


(2) X.500 based White Pages Server already enabling access to telephone books 
over 100 organizations 


(3) USENet News Server already supporting 84 client systems' accesses to over 750 
news groups 


(4) EIG supports e-mail, file transfer, and remote logons between DECnet and 

TCP/IP; NICOLAS extends e-mail and file transfer interoperability to BITNET and 
X.25 sites and auto-logons to several Internet/OSSA system resources 


(5) PMDF based Mail Server already supporting ROSAT and MU-SPIN Projects and 
GSFC LAN users 



NSI User Support Services 


User Conference Support 

• Provide NSI access booths and assistance at user conferences/scientific 
meetings, e.g., AGU Conference December 3-7, 1990 

• Present NSI capabilities through active participation in user symposia/ 
working groups 

• Demonstrate interoperability solutions 

• Present tutorials on effective networking applications 

• Make selected site visits for user training 

• Provide coordination and logistic support for NSI User Working Group meetings 


NSI Network Applications Development 


Requirements Definition and Analysis 

• Survey/conduct interviews on use/discipline needs 

• Survey emerging vendor products 

• Survey applicable R&D efforts in the Internet/OSI communities 

*> Host symposia, working group meetings, and electronic conferences 

• Recommend/consult with: 

- Users/disciplines on state-of-the-art in network applications 

- Vendors/developers on prioritized requirements 
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NS1 Network Application Development 


New Core Developments 

• Natural extensions to NSI’s Baseline services 

• Largely conducted by NSI "in-house" team 

• Includes joint development with user disciplines 

• Often complementary to NSI's Engineering testbed initiatives 

• Typical developments: 

- New X window applications 

- OS! based user utilities such as X.500 based OSSA Resources Guide 

- Techniques enabling/enhancing distributed applications 



NSf Network Applications Development 


Exploratory Developments 

• Significant involvement by wider networking research community 

• Protocol extensions and modifications 

• Examples of advanced applications: 

- Distributed Programmers Workbench 

- New distributed processing techniques 

- Group communications 

- Remote data visualization and manipulation 

- Interoperating data bases 

■ Knowbots and expert systems 
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NSI Network Applications Development 
New Core/Exoloratorv Development Plans for FY91 

• Mail Exploder System 

- Either patterned after SolarMail or based on PMDF 

- After development, system can be hosted on NSI or user facilities 

- Dr. Gunther Riegler/SZ targeted as initial user in mid-FY91 

• Utility to Support Distributed Heterogeneous Processing 

- Simplify use of RPC mechanism to support distributed processing 

- Demonstrate use among VAX, CRAY, and MarPar hosts 

- Dr. Gene Feldman/GSFC targeted as initial user in GSFC DAAC VO 

• Extended FTP Support for Off-line Data 

- Use familar standard user interface of Anonymous FTP but extend FTP 
utility to either wait or retry until requested data on off-line CD-ROM is 
mounted 

- Joint project with HEASARC's Dr. Michael Van Steenberg/GSFC 


NSI Network Applications Development 


New Core/Exoloratorv Development Plans 

• FY91 

- Develop Mail Server/Exploder such as requested Dr. Gunther 
Riegler/SZ 

- Develop utilities to simplify distributed heterogeneous processing; 
demonstrate use in GSFC DAAC VO application of Dr. Gene 
Feldman/GSFC 

- Extend FTP support to off-line data in joint effort with HEASARC's 

Dr. Michael Van Steenberg/GSFC 


• FY92 

- Provide X Window based version of NSINIC 

- Expand X.500 based White Pages support for disciplines/projects 

- Initiate X.500 based Yellow Pages support for an on-line OSSA 
Resources Guide 

- Develop selected applications identified via WBS 5.1 process 


• FY93 

- Assess and apply FTAM, Virtual Terminal, and other OSI based applications 
in NSI's OSI testbeds and operational network 


Develop additional selected applications identified via WBS 5.1 
process 


MSI User Support Services and Network Applications Development 


Conclusions 


• Refinement to the objectives and plans of the NS! elements under GSFC 
responsibility Is on-going and will continue to be influenced by: 

- User input/feedback through meetings with NSSUWG and user discipline 
programs 

- MSI Science Steering Committee advisory process 

- Support and guidance from NSI Program Manager at NASA OSSA 

- GSFC's allocation of NSI's budget and GSFC staff expertise 

• For further information or comments on GSFC's NSI efforts, contact: 


J. Patrick Gary 

Head, Advanced Data Flow Technology 

Office 

Code 930.4 

Goddard Space Flight Center 
Greenbelt, MD 20771 


301-286-9804; FTS-888-9804 
PGARY@DFTNIC.GSFC.NASA.GOV 

SDCDCL::PGARY 
JGARY in GSFCMAIL 
Fax: 301-286-5152 
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-OVERVIEW- 
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MSI SECURITY TASK 

AS FUNDED FOR FY9Q: 

POLICIES AND SECURITY DOCUMENTATION 
RISK ANALYSIS AND MANAGEMENT 
COMPUTER EMERGENCY RESPONSE TEAM 
INCIDENT HANDLING 
TOOLKIT DEVELOPMENT 
USER CONSULTING 

WORKING GROUPS/CONFERENCES/COMMITTEES 


rdt -2 



NSI SECURITY TASK 


FY90 STRUCTURE: 


Reports to NSIPO/ARC Administration 
Separate Task Assigned to GSFC 

STAFFING: 


Security Administrator, NSIPO/ARC - Yvonne Russell 
Security Manager, GSFC - Ron Tencati 


Other staffing as required by task by either NASA or contractor personnel. 



B 



CURST 


POLICIES AND DOCUMENTATION 


The Network Policies and Procedures Define the Official Security 
Requirements for Computer Systems Comprising NSS. 

• Official Policy 

• Security Guidelines (UNIX, VMS, DECnet, TCP/IP, X.25) 

Allows for the establishment of a "Security Baseline" for the network 
consistent with Federal Laws and NASA Regulations. 

Will Draw Upon Existing Documentation Where Applicable. 
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NSI SECURITY TASK 


RISK ANALYSIS AND MANAGEMENT 

Produce NSI Risk Analysis Document. Perform a NETWORK Risk Analysis. 

Require Periodic Risk Analysis of Constituent Systems Through Project 
MOUs. Provide Assistance Where Necessary. 


The Computer Security Act of 1987 requires as! Federal Computer Systems to perform 
Risk Assessments at least once every 5 years. Sooner for more sensitive systems. 


NIST is under contract with NSI and Code NTD to provide NSI with guidance and 
assistance in establishing a network risk analysis and management plan. 


rdt -5 
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NSI SECURITY TASK 


COMPUTER EMERGENCY RESPONSE TEAM (CERT) 

Formed after Morris and WANK Worms hit NSI component networks. 

Implements NSI-CERT for distribution of security-related notices, alerts and 
bulletins, as well as provides for coordinated distribution of software patches. 

• Identifies Site Security Contacts 

• EMAIL, PHONE and FAX Communication Possible 

Interfaces with NASA-wide CERT activity at HQ (Code NTD) 

NSI is charter member of Cert System, an International group of Government, 
Agency and Corporate CERTs. 
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MSI SECURITY TASK 


INCIDENT HANDLING 

Provide investigation, coordination, reporting and follow-up for Security incidents. 

Provide a place where system managers can report incidents or receive help 
regardless of operating system. 

Interface with NASA Inspector General and other Federal agencies as necessary 


rdt -7 
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SECURITY TOOLKIT SOFTWARE 


Provide user community with a set of self-audit tools to improve the 
security of their systems 


Operating -System independent (Two sets of equivalent tools for UNIX 
and VMS) 


Usage endorsed by NSI, recommended by Policy Documentation, but not 
required for membership in NSI. 


FY90: NSI-approved tools first, NSI-developed (maybe) later. 
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NS! SECURITY TASK 


USER CONSULTING 


Provide help for users with specific security problems. Receive referrals 
from NSI User Support Office. 


WORKING GROUPS/CONFERENCES/COMMITTEES 


Ensure that the security Interests of NASA Science Networking are 
represented as appropriate. 


rdt -9 
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NS* SECURITY TASK 


EXTERNAL CONTACTS 


Work with, and provide support to other Agencies and NASA Codes to 
facilitate a common Agency-wide approach to computer security. 


NIST: 

Under contract by NS! and Code NTD to assist NASA in addressing 
various computer security issues. 

• Analyze NSI and SPAN Risk Management Plans, Recommend 

modifications to allow NSI approach to match NASA AIS Program. 

• Identify network threats, survey existing toolkits (NSI and public 

domain, make recommendation for NSI strategy. 

• Review NASA Incident Response Capabilities, assist in the 

establishment of a NASA agency-wide CERT Capability. 

NSI is being used as the model for NASA networks 


rdt -10 
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GOALS: STRATEGIC PRIORITIES 


Extend U.S. technological leadership In high 1 

performance computing and computer 
communications 

Provide wide dissemination and applicatin of the 
technologies both to speed the pace of innovation 
and to serve the national economy, national security, 
education, and the global environment. 

Spur gains In U.S. productivity and industrial 
competitiveness by making high performance 
computing and networking technologies an integral 
part of the design and production process. 


NA§^clenceTntemef 
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High Performance Computing & Communication 



STRATEGY: INTEGRATING PRIORITIES 


Support solutions to important scientific and technical 
challenges through a vigorous R & D effort 

Reduce the uncertainties t© industry for R&D and use of 
this technology through increased cooperation between 
governments industry, and universities and by the 
continued use of government and government-funded 
facilities as a prototype user for early commercial HPCC 
products. 

Support the underlying research, network, and 
computational infrastructures on which UI.S. high 
performance computing technology is based. 

Support the U.S. human resource base to meet the needs 

of industry, universities, and government. 


NASA Science internet 
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High Performance Computing & Communications 

PR OGRAM COMPONENTS 

High Performance Computing Systems (HPCS) 

• 1000-fold increase in computing power 

Advanced Software Technology and Algorithms (ASTA) 

• Grand Challanges applications 

National Research and Education Network (NREN) 

• R&D and wide-area gigabit communications 

Basic Research and Human Resources (BRHR) 

• Infrastructure, training, education 


NASA Science Internet 
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High Performance Computing & Communications 


• interconnect 


MULTI-AGENCY PROGRAM 

• NSF, DARPA, DOE, MASA; also NIST, HHS, NOAA & EPA 




NASA Science interne! 




NREN Program Relationships 


The HPCC agencies (NSF, DARPA, DOE & NASA) have 
demonstrated dose collaboration in their networking activities, 
and they are developing more formal structures for the close 
coordination needed to ensure success of the NREN. 


DARPA will coordinate gigabit network technology 
research and development activities in which 
DARPA, DOE, NASA, NIST, and NSF will 

participate. 

NSF will coordinate the broad deployment of the 
NREN by working with all participating HPCC 
agencies through formal structures, such as the 
FCCSET subcommittees and the Federal Network 
Council. 

In conjunction with the other HPCC agencies, 

NIST will identify and develop network and 
security standards. 






The HPCC Program 


OSTP-FCCSET 1989 


advanced prototype 
evaluation of early s 


y systems 


2. Software and Algorithms grand challenge problems 

SW components and tools 
computational techniques 
HPC research centers 


3 J National Research and 
^ Education Network 


Basic Research am 
Human Resources 


Interim NREN 

gigabit networking research & deployment 
transition to commercial service 

instrumentation and lab Improvement 
education and training 
basic CS & CE research 
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Barciort - Curtis 
MRG (many) 
OSTP/FCCSET process 



Agency Initiatives 
MSF Supercomputer Centers 
IPA Teraops 

^SA Telescience' Initiative 


'Strategy 


HPCC Program, 

“Gore Bill" (Si 067), etc 

\ 


FCCSET 


IET and Internet Cooperation Planning 


OSIP 

initiative 
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— « NSFNETT1 Backbone 
— ■ Mia-level Connections 

Geographic Area of Mid-level Network 
Mid-level Network Hub 

Supercomputer Center & Mid-level Network Hub 




9 1990 Expansion sites 

* T3 Sites (Phase 1) 
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NSFMET Traffic Mm 


Mail, BB's & 
Conferencing 

-25 % 



File Transfer 
-25 % 


Other 

-18% 


Interactive 
-20 % 


Name Service 



* All estimates ± -2% 
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National Network Hierarchy 


NSFNET 


Regional/Network 


Corf orate Net 


mpus Net 


Local Area N 



Value Added Net 


USERS 

( electronic mail, file transfer, logon, etc.) 
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Initial NREN 
Implementation Plan 


Stage 3 

Gbits/sec 

IMREM 

Stage 2 

45Mbits/sec 

1MREM 

Stage 1 
1 .5 Mbits/sec 
Internet 
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Management Approach to NREN 
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HPCC AGENCIES 
NSF, DARPA, DOE, NASA; 
NIST, NCAA, EPA, NIH 
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FEDERAL NETWORK COUNCIL 

(Chaffer) 


• FORMED by FCCSET Network Subcommittee Chair (Jan, 1390) 


• PURPOSE: to establish an effective interagency forum and 
long-term strategy to oversee the operation and evolution of 
the Internet and other national computer networks in support 
of research and education. 


9 FNC will coordinate with FCCSET to ensure national alignment. 


• WORKING GROUPS will be established to support the FNC; 
members will be limited to Federal employees, Government 
contractors/grantees, or members of Federal advisory groups. 


• FNC will meet at least 4 times per year. 



FNC, coordinating with OSTP, will establish a charter and formal 
Advisory Committee representing industry and academia and the 
national user community; this Advisory Committee will work 
closely with the FNC to provide guidance in developing the NREN. 
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ndustry-University-Government 
High Speed Network 
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Bell Atlantic, 
MCI, NYNEX 






C. Network Technology Sessions 
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NASA'S USE OF 
FTS2000 SERVICES 

D. Scott/M S FC- A S53 

PSCN Systems Engineering Branch Chief 


0082 NASA FTS2000 JWL 2/7/91 1 


N91-27G18 
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NASA's Use of FTS2000 Service 


• Overview 

• Role of Program Support Communications (PSC) 

• Status of transition to FT32000 services 

• Issues 


NASA-PSC 


0082 NASA FTS2Q00 JWL 2/7791 2 
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NASA's Use of FTS2000 Services 


OVERVIEW 

• Public law and Federal Information Resources Management 
Regulation (FiRMR)“60 require NASA to use FTS200Q services 
that meet NASA requirements 

• NASA 0 s single point-of-contact for GSA in all policies and 
procedures dealing with FTS2000 is Code 0, S. Bates/ 
Telecommunications Agency Coordinator 

• Code O has delegated the PSC program as the focal point for 
ordering and coordinating all FTS2000 services. The PSC is a 
Designated Agency Representative (DAR) 

• NASA is committed to transition to FTS2000 switched voice and 

interlata dedicated-circuit services 

NASA-PSC .. 


0082 NASA FFS20OO JWL 2/7/91 3 




140 


NASA's Use of FTS2800 Services 

ROLE OF PROGRAM SUPPORT COMMUNICATIONS (PSC) 

• NASA=wide resource serves: 

NASA long-distance telecommunication requirements 
NASA International telecommunication requirements 
Administrative, scientific, and programmatic requirements 


NASA-PSC 


0082 NASA FTS200Q JWL 2/7/91 4 



NASA's ■ .s of FTS2000 Services 

ROLE OF PROGRAM SUPPORT COMMUNICATIONS (PSC) (CONT) 
• Centralized resource management provides: 

Requirements forecasting and budgets (PSCRB) 
Engineering design and intagration 
Equipment procurement 

Installation and testing of telecommunications resources 

Trouble reporting and maintenance 
- Network Control Center 

FT32OO0 coordination 


©082 NASA FTS2000 JWL 2/7791 5 
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NASA's Use of FTS20OO Service 


STATUS 


• Switched“¥@Ice service was transitioned at all NASA sites 6/90 

• Identified 1704- dedicated circuits to be transitioned starting 
5/91 . All analog data services will be upgraded to digital service 

• Identifying requirements by service type for submission to 
GSA- This will result in development of implementation plans 
and schedules for those services that FTS2000 can satisfy 

• Transition costs are funded by Code O 


NASA^PSC 
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NASA's Use of FTS2000 Services 


ISSUES 


• intervals for service is now 89 workdays (121 calendar days) 
after QSA approval 

• Backbone diversity is not an FTS2000 offering 

• Availability of DS-3 facilities 

• Extended Superframe Format (ESF) monitoring of T-1 facilities 

(facility data link) 


© 


Services not presently available require contract modification 
(upscale) 

NASA-PSC 


0082 NASA FTS2000 JWL 2/7/91 7 


FTS200 Network Architecture 


J. Klenart 
February 13, 1991 
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April — DOD agrees to use FTS 2000 
services when possible but retains 
power to decide when network use is 


March — MCI protests FTS 2000’s extension to 
non-government entities — specifically HHS’ 
plan to use the network to link its Child 
Support Enforcement Network (CSEnet) to 
state agencies. — — 



Time Lin 


Jorne 24 — Transition of long-distance 
voice services from old FTS to FTS 2000 
complete; 1.3 million users now served 
by the new system. — ~ 

~iuioe 5— MCI protests to GAO tbe^Buresu~ 
of Prisons’ decision to use FTS 2000 for 
inmates’ private phone calls. 



Carol Hall rules the network can be 
used for HHS* CSEnet 


May 26 — Federal Communications Commission 
approves AT&T s tariff for FTS 2000. 


Feb. 20 — GSBCA and GSA dismiss MCI and 
Martin Marietta protests of award to AT&T. — 


Oct. 7 — Voice cutover 

to FTS 2000 begins. 

March 20 — GSA kills major telecommunications 
buys at Justice and Labor and amends or cancels a 
dozen other agency networks to enforce mandatory 
FTS 2000 use. 


Feb. 6 — MCI goes to the GSA's Board of Contract 
Appeals and Martin Marietta to GSA to protest 
AT&Ts award. — 


Feb. 13 — GSA suspends funding for unawarded 
telecommunications projects at 18 agencies. 


t 


Oct. 31 — Michael Corrigan named deputy 
commi ssioner of 1 RM S at GSA for 
telecommunications, including FTS 2000. 

August— Bernard J. Bennington, who has run the 
FTS 2000 procurement, leaves GSA for a one-year 
sabbatical at the National Science Foundation. 

IRM5 commissioner Frank Carr takes over 
responsibility for FTS 2000. 

March 14 — GSA names members of an independent 
advisory committee to oversee bid evaluation. 

Jan. 28 — Amended RFP that provides for 

award to two primary vendors is issued. 


Dec. 7 — Contracts to provide FTS 2000 services awarded; 
AT&T gets 60 percent, US Sprint 40 percent 

Nov. 30 — Contract for Technical Services and 
Maintenance in support of FTS 2000 awarded to 
Contel Federal Services Corp. 


September — Congress makes use of FTS 2000 
mandatory for executive-branch agencies. 

April 29 — Vendor proposals for FI'S 2000 due. ♦ 

February — EDS drops out of the running a second 
time. US Sprint, ED^S* bid team partner, decides to 
continue in the competition as a prime contractor. 


December — Original contract award date. 


Oct. 30 — RFP revised to provide 
awards to two primary vendors. — 


Nov. 30— EDS re-enters 
competition for FTS 2000. 


June — Electronic Data Systems Corp., originally 
teamed with US Sprint, withdraws from the FTS 2000 
race, leaving two teams — one led by AT&T Co. and the 
other by Martin Marietta Corp. 


Sept. 27 — GSA, responding: to pressure from 
Reps. Jack Brooks (D-Texas) and Glenn English 
(D-Okla.), agrees to award FTS 2000 to two 
prime contractors. 


Oct. 24 — GSA publishes 
second draft RFP. 


Dec. 31 — GSA issues first RFP. 


Feb. 13 — GSA holds first briefing 
for industry and press. * 


Oct. 1 1 — GSA issues first draft 
request for proposals. 


GSA first announces intent to replace 
21 -year-old analog Federal 
Telecommunications System. 
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EQUIPMENT SUPPORTED 


FTS2000 

dedicated 

transmission 


Telephones 
Personal Computers 


£ • J * _S S»!i ! I . » * 


Mainframe Computers 
Facsimiles 

PBXs (analog and digital) 






N91-27020 


MuttINet TCP/I 

for 

WAX/VMS 

Update 


L. Stuart Vance 


IgV 

Copyright © 1990, 1991 TGV, Inc. 
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Multiset TCP/IP for VAX/VMS Update 

Multi-protocol networking services (TCP/IP, 
CHAOSnet, PUP) for VAX/VMS computer 
systems 

Currently shipping Multi Net V2.2 
Single kit for VMS V4.5 - V5.4 


Device Support 


Ethernet 

• All Digital controllers 

• CMC ENP family in link mode 

• Excelan/Novell EXOS family (except 

Bl board) in link mode 

• Interlan Nil 010 

• Xerox 2.94 Mbps Ethernet 

Other Technologies 

• NSC Hyperchannel 

• Shared Proteon proNET-10, 80 

• X.25 - ACC 5250/6250 

• T1/HDLC- ACC 5100/6100 

• DMR-1 1 , DMV-1 1 (IP over DDCMP) 

• SLIP - using any VMS terminal line 
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DECnet Interoperability 




Installation 


• VMSINSTAL - painless 

— 99% of configurations supported 

— 15 minutes or less on most newer systems 

• Configuration utilities 

— Handle all aspects of network configuration and 
operation 

— Perform sanity checks to ensure viable 
configuration 

— Automatically generate all startup command files 
— Utilities: 

• Network/devices • Remote printer queues 

• Services • DECnet over IP 

• Client and Server NFS 
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MultiNei Services 

• Although servers may listen on their 

own for service requests, the Master 
Server provides an easier way of 
invoking sen/ices 

• Inbound connection requests handled by 

Master Server (configured by the server 
configuration utility) 

• Accepts or rejects connection; if it accepts, 

it either: 

— Peforms the service internally, or 
— Creates a server process and passes 
the connection on SYS$INPUT, 
SYS$OUTPUT, ... 

• Can restrict access on source host or net 

address on a per-service basis 

• Keep an audit trail of attempted, accepted, and 

rejected requests on a per-service basis 

• Sites can provide locally written Auditing code 

• Internal servers may be linked in or 

dynamically loaded from shareable images 
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Domain Name Server 


• BIND 4.8.1 + Partial Asynchronous Zone Transfers 
9 Runs internal to Master Server 

• NSLOOKUP provided 

9 If Domain Name System (DNS) query fails, or DNS 
not enabled, lookups use host tables compiled 
using a perfect hashing scheme 

Routing Protocols 

• GATED 1.9.1. 7 

• Runs internal to Master Server 

• Supports RIP, EGP, HELLO 
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Telnet 


• Direct connection between VMS terminal 


— Overhead about the same as a DZ-1 1 


• Virtual terminals supported 

• Negotiations 

— Terminal type (SMG) 

— Window size 
— Baud rate 

— Flow control (negotiated local by default) 

— TN3270 automatic recognition 

• No inherent limit on number of incoming connections; 

customer running with 150 connections into a VAX 6230 

• Optional switches to bypass newer option negotiation 

features for compatibility with other broken Telnet 
implementations (antique-mode) 
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FTP 


• Hybrid server 

— initially runs internal to Master Server 
— When USER and PASS are received, 
LOG1NOUT is invoked to validate, 
initialize, and run the FTP server 
process 

• Supports all VMS security features: 

— ACLs (not just UIC ACLs) 

— Accounting 
— Auditing 

— Breakin detection and evasion 
— Security alarms 

• Runs SYLOGSN.COM, LOGIN.COM 

• Creates FTF__SRRVER.LOG file in login 

directory with log of transactions 

• STRU O VMS 

— Transparent VMS-VMS transfer of all 
VMS file types 

■ — Automatically negotiated 
— Fast, no reformatting needed 

• Record structure also supported 

• Performance: 

• — MicroVAX 11 can saturate DEC Ethernet 
interfaces 
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SMTP 


• Uses VMS Mail foreign protocol interface: 

SMTP%"user@node" 

• Enqueueing done with VMS server queue 

(using VMS queue management) 

« MX support 

• Tries all IP address found via "A" records 

until successful 

• Incoming and outgoing mail enqueued 

(allows incoming mail to be forwarded 
to an unavailable DECnet node) 

• MM-32 user interface bundled with 

MultiNet 

• VMS Mail SET FORWARD and SET 

PERSONAL-NAME supported 

• Supports outbound cluster (or 

organizational) alias 

• PMDF supported as alternative (fully 

functional email gateway) 
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DECwindows over TCP/IP support provided 
by emulation of the VMS/ULTRIX 
Connection (UCX) $Q!0 interface 

Looked into using DECwindows transport 
layer interface, but decided to do UCX 
$QIO emulation as a more general solution 
(to support other applications written to run 
over UCX) 



RLOGIN — remote terminal protocol 

RSHELL/REXEC — remote command execution 

RCP — remote copy protocol 

RMT — remote access to VMS tape drives 

Each uses "r" services autherntication 
(HOSTS. EQUIV and .RHOSTS) 



Remote Printing 


• LPD protocol client and server 

— Integrated with VMS queueing system 
— UNIX machines can print on VMS 

printers 

— VMS systems can print on UNIX 
printers via a VMS print queue 
(symbiont and spooled 
pseudo-device) 

• Stream-mode symbiont sends print jobs 

directly to remote TCP port (useful for 
printers connected to terminal servers) 

• Controlled by printer configuration utility 

• Supports VMS accounting 

• User definable /etc/printcap to VMS 

print queue attribute mapping 
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Full UN IX filesystem semantics mapped to VMS 

filesystem 

Respects VMS diskquotas 

VMS text files are converted to UNIX stream format for 
access from NFS clients 

Cache to mask VMS bottlenecks 

Supports all ODS-2 VMS volumes: 

— Shadow sets — Bound volumes 

— DFS served disks 

Very high performance 

— Multi-threaded so performance not degraded by 

multiple clients 

— Runs in the kernel, so no process context 

overhead involved 

— Uses a special XDR serializer 


NFS Client 

*> Transparent file access to NFS servers from 
VAX/VMS systems 

» Emulates Files- 1 1 ODS-2 XQP, presenting 
virtually all of the VMS file system semantics 

• Supports arbitrary RMS file/record types with text 

files mapped to RMS StreamJLF record type 

• Performance, even with majority of code in 

process for debugging, is good (within a factor 
of 3 of a local disk) 
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Allows privileged users to control servers running 
internal to the Master Server 

Can be used to control both local and remote 
machines (using Multi Net security features) 

MULTINET NETCONTROL /HOST=TGV.COM 
NFS RESTART 


Diagnostics 


• PING - uses ICMP packets to determine 
reachability, packet loss, round trip timing 


* TRACEROUTE - trace route of a host through an 
IP network 


• TCPDUMP - Ethernet protocol analysis 
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Programming Support 

Shareable 4.3BSD UNIX compatible socket library 

Programmer's kit separately installed (MNETLIB) 

Hardcopy Programmer's Guide and extensive online 
HELP information 

MultiNet $QIO (compatible with WIN/TCP), EXOS 
compatible $QIO, and UCX compatible $QIO 
interfaces supported 

RPC programming library 
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Miscellaneous Features 


• FINGER 

• WHOIS client 

• NETSTA I 

• SYSTAT 

• TFTP 

• BOOTP 

• RARP 

• NTP 

• TALK/NTALK 

• BBOARD 


• RUSERS 

• RWALL 

• REMIND 

• CHARGEN 

• DAY I IME 

• TIME 

• DISCARD 

• ECHO 

• RPCQUOTA 




• ALL-IN-1 /Message Router to SMTP gateway 

capability 

• VMS NFS Client to VMS NFS Server support 

• Performance enhancements in NFS Client and 

Server 
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MultiNet Futures 


• Support for booting diskless Sun workstations 

and DECstations 

• Full support for VAX-1 1 C runtime socket library 

(run UCX applications unmodified over 
MultiNet) 

• GATED V2.0 - EGP, RIP, HELLO, BGP 

• BIND 4.8.3 

• POP2 Mail Server (possibly more) 
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D. Science Networking Keynotes 
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Science Network Resources: 
Distributed Systems 

Neal Cline 
February 13, 1991 



DATA SYSTEM ENVIRONMENT 



Directory - Brief overview Information about whole data sets 

Catalog - More detailed Information about whole data sets 

Inventory - Information about individual granules or elements of the data set 


MASTER DIRECTORY 













WHAT IS A PROTOTYPE INTERNATIONAL DIRECTORY? 


EMBBQME 

• An online information system for rapid and efficient identification, 
location, and overview information on data sets of interest to the 
science community 

• Initial place to search for data - leading to catalogs and inventories 
having more detailed information about the data 

• Automated network links to other systems having more detailed 
information and possible additional capabilities 


FEATURES 

• No training needed • International 

• Open, free access • Data center/archive descriptions 

• Interdisciplinary • Gampaign/project descriptions 

• Earth and space science data 
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ADVANTAGES OF ON-LINE DIRECTORIES 


• Provides data information to the science community 2^ 


• Contains up-to-date information on the well-known data as well as th< 
lesser-known data sets in remote locations 



Permits Immediate links to other on-line information systems whicl 
provide more detailed information 


information can be periodically extracted onto CD-ROM or floppy disk 
format for use in personal computer systems 

— — — * MASTER DIRECTORY 


INTERCONNECTED DIRECTORY ASSUMPTIONS 


• Directory service will be provided free of charge to the science community 


• The DIF files will be used as the standard of directory Information 
exchange 


• DIF files submitted to one node will be distributed, through an established 
procedure, to all nodes of a directory system 


• DIF flies will be reviewed at procedurally-determined locations according to 
standards defined for the system 



Copies of the final, reviewed DIF entry are retained at the reviewing 
location and by the DIF author* The author copy is the master copy. 


TEH DIRECTOR 
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DIF - EXCHANGE FILE FOR DIRECTORY INFORMATI 



Description of a data set Is written in the Directory Interchange Fori 
then passed among directories and automatically loaded 



mpi 

• A standard developed by Catalog 
Interoperability Working Group 
(federal agency and academic 
representatives) 

• Simple ASCII text file 

• Usually 2-3 typed pages In 
length 


• In use by federal agencies, 
academia, European countries, 
Japan, Russia 

• Described In DIF Manual 
(contact Jim Thleman) 

• Maintained under change contra 



MASTER DIRECTORY 








SPECIFIES SYNTAX STANDARDS [PARAMETER: VALUE] 

SPECIFIES THE PARAMETERS CONSTITUTING A MASTER DIRECTORY 
ENTRY: 

- TITLE 

- START AND STOP DATA 

- SENSOR 

- SOURCE 

- INVESTIGATOR AND TECHNICAL CONTACT 

- DATA CENTER 

- CAMPAIGN OR PROJECT 

- STORAGE MEDIUM 

- PARAMETER MEASURED 

- DISCIPLINE KEYWORDS 

- SPATIAL COVERAGE 

- LOCATION KEYWORDS 

- GENERAL KEYWORDS 

- REFERENCES 

- SUMMARY 


MASTER DIRECTORY 





184 


Brief Summary/Abstract 

Data Source Name (Spacecraft, Platform, etc.) 

Sensor Name 


Storage Medium 


Parameters Measured 
Location Name 
Latitude/Longitude Coverage 
Bibliographic References 
Maine, Address, Phone, etc. for: 
Investigator 
Technical Contact 
Data Center Contact 


MASTER DIRECTORY 


00 



^ ^ ? 'MM;- 

w&m 


0 >^ 


DIRECTORY POPULATION STATUS 


ercentage of Directory Entries by Discipline 


Earth Science 
Planetary Science 
Solar Physics 
Space Physics 


Total Entries = 768 

(includes some multi-discipline entrie 

— MASTER DIRECTOR 



DIRECTORY INTERCONNECTIONS STATUS AT GSFC 


PRESENT 

ADC - Astronomical Data Center 

EDC - EROS Data Center Data Ordering Mailbox 

1UE FACILITIES - IUE Processing Facilities 

LEDA - ESA Land Observations Data Inventory 

NCOS - NASA Climate Data System 

NODS - NASA Ocean Data System 

NSSDC - NSSDC Data Ordering Mailbox 

OMNI - Interplanetary Medium Database 

OCEANIC - Ocean Network Information Center 

PDS - Planetary Data System 

PLDS - Pilot Land Data System 

SDCS - SAR Data Catalog System 

TOMS - NIMBUS-7 Total Ozone Mapping Spectrometer Data 
Assorted Dynamics Explorer Data Set Catalogs 

Note that there are approximately 40 data systems/centers now described in 
the directory. The ones above can be connected to automatically from the 
a directory through the LINK command. 

- — l ± MASTER DIRECTORY 


DIRECTORY INTERCONNECTIONS STATUS (CONT.) 


FUTURE 


BRUNET REQUEST - UCLA Space Physics Data System 

CEOS PID - CEOS Prototype International Directory System (Europe, Japan) 

IRPS - Image Retrieval and Processing System (Washington Univ.) 

NASA ARIN - NASA Aerospace Research Information Network 

NASA GISS - NASA Goddard institute of Space Studies 

NASA RECON - NASA REmote CONsole - (NASA Scientific and Technical 

Information Database) 

NQAA NESDD - NOAA Earth Systems Data Directory 

UA - GEODATA CENTER - University of Alaska Fairbanks/GeoData Center 

USGS ESDD - USGS Earth Science Data Directory 


MASTER DIRECTORY 


DIRECTORY STAFFING AT GSFC 




The number of staff reflects the role of GSFC as a coordination point for 
software and database content. (Not all personnel are full-time) 

— MASTER DIRECTORY 














ACCESS TO DIRECTORY AT GSFC 


$ SET HOST NSSDCA 
USERNAME: NSSDC 

oiNnnE»inr 

TELNET 128.183.10.4 
USERNAME: NSSDC 

mrnrn 

GOTO NSSDC 


wmM y mm 

Dial 301-286-9000 
CONNECT 1200 (or 2400 or 300) 
Enter several carriage returns 
ENTER NUMBER 
MB 

CALLING 55201 (or 55202) 

CALL COMPLETE 

Enter several carriage returns 

USERNAME: NSSDC 


ITALICS INDICATE RESPONSE FROM THE COMPUTER 
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OVERVIEW of the ADS 

AGENDA 


o The Problem 
o The ADS Project 
o Architectural Approaches 
o Elements of the Solution 
o Status of the Effort 


o The Future 



OVERVIEW of the ADS 
The Problem 

o Drinking from the Fire Hose 
o Multi-Spectral Research 
o Real-time Observing / Coordinated Observations 
o "Data about Data" and Tapping Human Expertise 


o Collaboration 





ADS OVERVIEW 
THE ADS PROJECT 


NASA ASTROPHYSICS DIVISION PROGRAM 

DR. GUENTER RIEGLER - MISSION OPERATIONS BRANCH CHIEF 
DR. FRANK GIOVANE - ADS PROGRAMS MANAGER 


ASTROPHYSICS DATA SYSTEM PROJECT 


DR. JOHN GOOD - PROJECT MANAGER 
DR. STEPHEN MURRAY - PROJECT SCIENTIEST 


DR. JOHN NOUSEK - USER COM Mi I I EE CHAIN 


ELLERY SYSTEMS, INC. - SYSTEMS INTEGRATION 



ADS OVERVIEW 

THE ADS PROJECT - continued 


CHARTER 

To Provide current and future generations of space scientists with direct, 
on-line access to existing and future multispectral data and analysis tools. 


OBJECTIVE 

The ADS is a production level distributed processing system. The Objective 
of the ADS is to make all science data holdings and all ADS Hardware and 
Software services available to all users transparently. 
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OVERVIEW of the ADS 


Architectural Approaches 

o The "rlogin" model 

- User accesses each site independently 

- User must have accounts everywhere 

- Tools and interfaces are generally site specific 

- Data Transfer is done in a different environment 

o The Client / Server Model 

- Global Uniformity 

- Standard Interfaces 

- Modularity 

- Separation of Processing and User interface 

- Easily incorporates existing services 

- Easily expanded and evolved 

- Location independence (of user, data, and processing tools) 



OVERVIEW of the ADS 

Elements of the Solution 


User Interfaces 
User Services 

- Distributed Access to Existing Database Systems 

- Document Location and Retrieval 

- Local Table Manipulation 

- Local Visualization 

System Services 

- User / Service Authentication 

- Help 

Glue 

- NASA Science Internet 

- Message Passing Service 

- Standard Data Formats and I/O 



ASTROPHYSICS DATA SYSTEM 
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ADS OVERVIEW 

ELEMENTS OF THE SOLUTION - SQL SERVER 


o Heterogeneous DBMS's 

- Relational 

- Heirarchical 

- Network 

o Distributed Interaction 


o Homogenization and Translation 
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ADS OVERVIEW 


ELEMENTS OF THE SOLUTION - FACTOR SPACE 


o Failure of the "Library" Model 
o Personal Perspective 
o Fields and Terms 


o Factor Spaces 
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ADS OVERVIEW 


DEVELOPMENT AND OPERATIONS PHILOSOPHY 


The ADS was designed and built by practicing astrophysicists for practicing 
astrophysicists. 

Utilizing the most advanced commercially available and supported 
distributed processing system technology, it is specifically designed to meet 
the evolving needs of the professional scientist and to provide the community 
with a powerful and immediately useful research and educational facility. 
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ADS OVERVIEW 


STATUS 


PHASE ONE: 

At present, data holdings from SAO and IPAC are accessible using advanced 
remote procedure call and other advanced distributed processing system 
techniques. Over the next three months, data holdings from IUE/GSFC, 
IUE/CASA, STScI, Penn State, and the NSSDC will be added to the system. 
Data holdings from all great observatory and explorer class missions will be 
added as available. 


PHASE TWO: 

Provide on-line access to existing and future data analysis and manipulation 
tools to include imaging/visualization, graphic analysis, statistical, and such 
other tools as deemed appropriate by the user community. These tools will be 
made available as distributed processed to maximize compute and software 

resource availability to the community. 
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ADS OVERVIEW 

TUC CIITIIDC 

i i i w i II. 


o System Generated Services 

- Transaction Management 

- System Monitoring 

- System Interfaces 

- User Interfaces 

- Communications Services 

o User Generated Services 

- Data Analysis 

- Visualization 

- Modeling 
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ADS OVERVIEW 
THE FUTURE - continued 


o Project Generated Services 

- Planning and Scheduling 

- Monitor and Control 


o Datasets 



- Spectra 

- Ground - Based Data 

- Textbooks and Journals 
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OVERVIEW OF THE ASTROPHYSICS DATA SYSTEM 


John C. Good and Richard B. Pomphrev 
Infrared Processing and Analysis Center 
Jet Propulsion Laboratory 
California Institute of Technology 
Pasadena, CA 91125 

Abstract 


The Astrophysics Division of NASA has built a geo- 
graphically- and logically-distributed heterogeneous in- 
formation system for the dissemination and coordinated 
multispectral analysis of data from astrophysics missions. 
The Astrophysics Data System (ADS) is a truly dis- 
tributed system in which the data and the required pro- 
cessing are physically distributed. To accommodate the 
anticipated growth and changes in both requirements and 
technology, the ADS employs a server/client architecture 
which allows services and data to be added or replaced 
without having to change the basic architecture or in- 
terfaces. Current datasets accessible through the system 
include all the tabular astronomical data available at each 
of six existing astrophysics data centers. Additional data 
nodes, at both NASA data centers and academic insti- 
tutions, will be added shortly. The future evolution of 
the system will be driven in large part by user services 
mounted both by the ADS project itself and by members 
of the astrophysics community. 

Astrophysics Data System Philosophy and Strategy 

Astrophysicists today have a bewildering array of 
powerful NASA resources to call upon. Among these are 
the data centers for the High Energy Astrophysics Ob- 
servatories (HEAO’s), the International Ultraviolet Ex- 
plorer (IUE), the Infrared Processing and Analysis Center 
(IPAC), and the Hubble Space Telescope Science Insti- 
tute (S'TScI), as well as the National Space Science Data 
Center (NSSDC). Unfortunately, the services provided by 
these centers are essentially independent and some are 
only accessible through mission- unique hardware and soft- 
ware. Furthermore, they can generally only be accessed 
directly through the centers themselves. 

The Final Report of the Astrophysics Data System 
Study, March 1988, characterized the data environment of 
the Astrophysics community at that time and defined for 
the future an “. . . architecture for a data system which 
will serve the astrophysics community in multi-spectral 
research through the decade of the 1990’s.” One of its 
recommendations was that each data set, and the hu- 
man expertise which supports the data, be maintained 
at the same physical location. Moreover, these multiple 
locations should be linked together and to researchers by 
means of high speed communications networks. Finally, 
to allow true multi-spectral research the various data sets 
should be accessible through a common set of tools. 

The Astrophysics Data System (ADS) Project is 
NASA's response to the Data System Study. For the sci- 
ence investigator, the ADS makes NASA’s current and fu- 
ture data holdings more broadly and efficiently accessible, 
and makes the data itself more interpretable. For NASA, 
it provides a common information system infrastructure 


for science analysis, thereby reducing duplication of effort 
while increasing the scientific return from missions. 

The ADS is a truly distributed system in which 
both the data and the required processing are physi- 
cally distributed. To accommodate anticipated growth 
and changes in both requirements and technology, the 
ADS employs a server/client architecture which allows 
services and data to be added or replaced without having 
to change the basic architecture or interfaces. The ADS 
design is modular and layered, enabling smooth evolution 
of the hardware and software without interruption of ser- 
vice to the user community. In addition, the ADS will 
provide all on-line information necessary to use the ADS 
services and data; and its design enables remote updating 
of the software services. 

ADS Software Architecture 

Conceptually, the software can be divided into two 
categories. Core Services are those which provide the ba- 
sic system functionality upon which user applications or 
User Services can be built. These will be built primarily 
by the ADS Project itself. User Services are other ap- 
plications which reside on the ADS and provide science 
support and analysis functions required by the investi- 
gator. These may be built by the Project in response to 
community demand or by individuals or groups funded by 
the NASA Astrophysics Science Research Aids (ASRA) 
Program. 

In its initial release, the ADS will provide basic Core 
and User Services. These will be expanded and supple- 
mented in the future based on feedback from the Astro- 
physics co mmun ity. 

Initial Core Services 

The MESSAGE PASSING SERVICE (MPS) enables 
remote inter-operability and data transfer/translation 
among the ADS services. It provides homogeneity across 
networks and operating systems for process requests and 
responses. While this service is largely invisible to the 
end user, it provides the application programmer (and the 
ADS system programmers) what the User Interface pro- 
vides for the science end user: an environment in which to 
access the services of the ADS from within an application 
program without knowing which servers will execute the 
program or the services it accesses. At a minimum, the 
MPS implements the functionality of: 

- Remote Procedure Call (RPC): a mechanism by 
which the subroutines of a program can call each 
other as if they were executing on a single server 
when, in fact, they may be segmented across several 
servers; 
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- Remote Process Invocation (RPI): a mechanism by 
which a program on one server can spawn programs 
on other servers; 

- Remote Inter-Process Communication (RIPC): a 
mechanism whereby two or more programs running 
concurrently on different servers can communicate 
among themselves. 

In the initial release, the ADS Message Passing Ser- 
vice conforms to the Advanced Network System Architec- 
ture Testbench (ANSAT) and the Open Software Founda- 
tion/Distributed Computing Environment (OSF/DCE). 

USER INTERFACES are the services which provide 
the local working environment (including its look and feel) 
to the end user. As such they provide a means to access 
all other services within the ADS. The structure of the 
ADS is such that there can be any number of user in- 
terface programs incorporating the constraints, hardware 
limitations, and preference of specialized segments of the 
community. Our efforts to date have concentrated on a 
single user interface which is structured to conform to a 
“least common denominator” hardware environment, and 
which provides an effective interface to the initial set of 
ADS Services. The ground rules have been: 

- the ADS system must be accessible using any charac- 
ter terminal supportable under the UNIX “termcap” 
facility (basically any display with 24x80 characters 
and an addressable cursor); 

- the ADS system must be effective (if slow) at 1200 
baud. 

- it must be possible (but not required) to configure the 
system such that the user interface and appropriate 
interactive processing is done at the user’s site, rather 
than at centralized facilities. 

- the user interface in particular should be available 
under UNIX, VMS and MS/DOS. 

Even with these constraints, we are able to provide an 
ADS User Interface that provides the following combined 
functionality: 

- specialized table display and interactive manipula- 
tion facilities; 

- a first-order complete relational database facility 
including support for Structured Query Language 
(SQL) and Query by Example (QBE); 

- Menu bar/pulldown menus and multiple windows 
(split-screen); 

- context-sensitive help and a dynamic tutorial facility; 

- full-featured text management facility that supports 
browsing, plain-text inquiry and cut-paste editing of 
selected files. 

Through this interface, investigators can locate data 
sets (descriptions and catalogs) of interest, access these 
data sets either individually or in combination, and select 
from among them one or more subsets that they wish to 
import into a local working environment for further analy- 
sis of their own choosing. More importantly, it allows the 
investigator to accomplish this wdthout requiring him to 
know which servers execute the services he invokes. In the 
initial release, the Knowledge Dictionary System (KDS) 
(tm) is being used to implement the functionality of the 
User Interface. 

The DATA INDEPENDENT ACCESS MODEL 


(DIAM) is a service which provides inter-operability 
and language conversion among the various distributed 
Database Management Systems (DBMS's) in the ADS. 
These DBMS’s include the following: Ingres and Sybase 
(UNIX), RDB (VMS), and IM/DM (CDC NOS/VE). The 
DIAM is required in the ADS in order to provide the user 
with a uniform relational view of all these distributed cat- 
alogs even though some of the catalogs are still maintained 
using DBMS’s that do not yet support the relational SQL 
standard. The functionality of the DIAM is: 

- to accept SQL statements generated by the User In- 
terface (either directly or indirectly using the QBE 
translator); 

- to convert them to the language supported by the 
DBMS that hosts the referenced catalog(s); 

- to RPI a process to submit them to the DBMS for 
processing and to collocate the resulting table(s); 

- to return those results to the User Interface that is- 
sued the request. 

The Distributed Access View Integrated Database 
(DAVID) system is being used to implement the func- 
tionality of the DIAM. 

Besides providing uniform access to the multiplicity 
of existing DBMS’s, DAVID provides a complete inter- 
nal distributed DBMS which allows further processing 
with special features not available in most commercial 
DBMS's. Of particular importance in a distributed en- 
vironment is its ability to allow dataset browsing. This 
minimizes the overhead potentially incurred by having to 
transfer data in large chunks around the country. 

Future Core Services 

There are several Core Services which are important 
and anticipated in the near future, but which were not in- 
cluded in the initial release of the Astrophysics Data Sys- 
tem. Among these are the User/Service Authentication 
Service and the Transaction Management Service. Other 
Core Services will be added on as they are required and 
become available. 

The USER/SERVICE AUTHENTICATION SER- 
VICE will provide the capability to automatically verify 
the authorization of a user to access the ADS System and 
to access specific services and data within the system. It 
will be provided through an implementation of the KER- 
BEROS software on the ADS System. 

The TRANSACTION MANAGEMENT SERVICE 
(TMS) will provide the process and resource management 
protocol for client-defined transactions. It assures suc- 
cessful execution, synchronization, and release of all ser- 
vices and resources used in a transaction. The TMS pro- 
vides two basic functions: 

- insure, without further client intervention, that ail 
the services requested during a transaction will lie 
successfully executed even if some of those services 
or the servers on which they are executing fail while 
the transaction is in progress; 

- insure, without further client intervention, that all 
resources involved in a transaction are properly *yu- 
chronized and released regardless of the destiny of 
the transaction (success or failure). 



The TMS is both an optional and a passive service; 
optional in that it must be explicitly invoked by the client; 
and passive in that, as a peer-to-peer system, there is no 
mechanism by which the TMS protocol can be enforced, 
and the only programs that are guaranteed to participate 
in the TM protocol are the core services of the ADS. To 
encourage the use of the TM by end-users and applica- 
tion programmers, the protocol has been kept as simple 
as possible, requiring only four commands: Begin, Lock, 
Upgrade, and End. 

Begin is a signal that a program is starting and re- 
turns a unique Transaction ID that the program must 
use in all subsequent calls to the TM. Lock signals the in- 
tent of the program to access the resource (e.g., a record 
in a file) named in the call. Upgrade signals the intent 
of the program to modify a previously Locked resource. 
End signals that the program is terminating, and the 
mode of termination (success or failure). For the initial 
ADS release, the components of the Transaction Manage- 
ment Service are implemented by the Transaction Man- 
ager (tm), which is an integral part of the Knowledge 
Dictionary System (tm). The TMS components will be 
exported as discrete services through the Message Passing 
Service through which they will be accessible by Remote 
Procedure Calls. 

Initial User Services 

The initial User Services available through the ADS 
have usually been collectively referred to as Directory 
Services, with components that provide access to cata- 
log data and to documentation about data holdings for 
specific Astrophysics archives, without requiring the user 
to know where the data physically resides. These Direc- 
tory Services include Document Retrieval, Documenta- 
tion Browse, and a Catalog Data Retrieval and Processing 
Service. Astrophysics data comes in several forms (e.g., 
catalog data, spectral data, image data). The initial re- 
lease of the ADS will be limited to catalog data (though 
some of the catalogs are in fact lists of images or spectral 
observations). 

The DOCUMENT RETRIEVAL SERVICE provides 
uniform, subject-matter indexing (and English-language 
querying) across all the data in the ADS, regardless of 
whether data are highly structured in databases, or un- 
structured. For the initial release, the Document Re- 
trieval Service is implemented by the Factor Space Ac- 
cess Method (tm) as an integral part of the Knowledge 
Dictionary System (tm). The various components of the 
Document' Retrieval Service will be exported as discrete 
services through the Message Passing Service, through 
which they can be generally accessed by Remote Proce- 
dure Calls. 

The Factor Space (FS) is an n-dimensional Euclidian 
space, the axes of which are statistically constructed to ac- 
count for the variance and covariance in expert judgments 
made by astrophysicists about the relevance of ADS data 
items to different subject matter contexts. The functions 
of the Document Retrieval service are: 

- to scan all data entered in the ADS and compute its 


subject matter profile as a sequence of one or more 
vectors in the Factor Space; 

- to similarly analyze natural language requests and to 
search the Factor Space for relevant data items; 

- to monitor the distribution of vectors in Factor Space 
for clusters (i.e. , undifferentiated data items); 

- to periodically generate, disseminate, collect and syn- 
thesize questionnaires to obtain additional relevance 
judgments needed to increase the data resolution; 

- to factor- analyze these additional relevance judg- 
ments and modify the number and/or orientation of 
axes in the Factor Space accordingly. 

These functions also support the generation of new 
Factor Spaces, either to accommodate new subject matter 
or to accommodate personalized perspectives on existing 
subject matter. 

The DATA BROWSE SERVICE provides a simple 
means for users to access and organize directories and files 
through the functionality of the User Interface described 
above. 

The DATA RETRIEVAL AND PROCESSING SER- 
VICE provides the capability to retrieve cataloged data 
and perform data base management processing on that 
data through the query, text management, and relational 
data base functionality of the DIAM and User Interface 
services described above. 

Future User Services 

It is expected that other User Services will be made 
available as they are requested by the Astrophysics user 
community and integrated into the ADS. Because of the 
flexible modular nature of the ADS architecture, such in- 
tegrations should be relatively straightforward and can be 
implemented in a variety of ways, dependent on how the 
prospective User Service is coded. These new services can 
be derived from any of the following sources: 

- Astrophysics Science Research Aids (ASRA) Pro- 
gram 

- NASA Astrophysics Flight Projects 

- Other NASA Flight Projects 

- Other NASA Programs 

- Non-NASA Programs 

- Non-US Programs 

ADS Physical Architecture 

An overview of the ADS physical architecture is pre- 
sented in the figure below. In its initial instantiation, 
the ADS will consist of six physically distributed primary 
nodes which are interconnected via NASA Science Inter- 
net (NSI). These six nodes are the following: 

- Center for Astronomy and Space Astrophysics 
CASA), Boulder, Colorado 

- Infrared Processing and Analysis Center (IPAC), 
Pasadena, California 

- International Ultraviolet Explorer (IUE), Greenbelt. 
Maryland 

- National Space Science Data Center (NSSDC). 
Greenbelt, Maryland 
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- Smithsonian Astrophysical Observatory (SAO), 
Boston, Massachusetts 

- Space Telescope Science Institute (STScI), Balti- 
more, Maryland 

Platforms and Operating Systems 

Each of these nodes above has important astrophysics 
catalogs for which it has principal responsibility. In gen- 
eral, these catalogs are maintained in different types of 
DBMS’s on different types of machines, each of which 
runs a unique operating system. Components of the 
ADS Core Services will be resident on a server at each 
node and connected by the ADS Message Passing Ser- 
vice software. (See the ADS Primary Nodes Compatibil- 
ity Requirements Document for a more detailed descrip- 
tion of the hardware interface.) The mapping of services 
to servers in the ADS is unconstrained: some servers si- 
multaneously provide several (simple) services while some 
(complex) services are segmented across several servers. 
In addition, the numbers and kinds of services that can 
be mounted on the ADS are also unconstrained. 



Physical/Logical Organization of Representative 
ADS Services. 


Nodes and Sites 

The ADS will be composed of Primary and Sec- 
ondary Nodes, an Administrative Node, and User Sites. 

An ADS primary node is defined as a facility which 
assumes primary responsibility for the provision of a 
unique service through the ADS infrastructure. This ser- 
vice can involve the provision of basic mission-specific 
data, as would be the case for a mission science support 
center like.IUE, or for the provision of an operational ser- 
vice for remote access such as the IPAC-supported NASA 
Extragalactic Database (NED). 

A Primary Node assumes the responsibility for user 
support, maintenance of user services, data, and appro- 
priate documentation it provides via the ADS. Many dif- 
ferent kinds of services may be offered by primary nodes 
in the future, such as access to data archives or use of 
specialized processors or software. 

A Secondary Node is not responsible for user sup- 
port or for maintenance of data or service provided by 
the node. Its role is to provide local or regional copies of 


data or services. Provision for such copies should allevi- 
ate the load on the primary nodes and. greatly improve 
the responsiveness and reliability of the system. 

The ADS will also maintain an administrative node 
whose primary functions are to monitor the system (the 
user/service database, network throughput and connec- 
tivity, usage patterns, service availability, and security), 
and to serve as the top of the hierarchy that deals with 
user questions, problems and training. 

A site is defined as any physical location, outside of 
an ADS Node, where ADS-specific software exists (e.g., 
the User Interface, MPS, or DIAM) through which an 
investigator accesses the ADS or its services. 

Networking 

The first release of the ADS required network connec- 
tivity among the primary nodes and remote users (those 
not physically located at one of the primary nodes). This 
network connectivity will be furnished by the NASA Sci- 
ence Internet (NSI) which supports the TCP/IP protocol. 
While it is intended that the ADS will eventually support 
the DECNET protocol, this will not be the case for the 
first ADS release. 

User Scenario 

The prospective user of the Astrophysics Data Sys- 
tem should first obtain a copy of the ADS User’s Guide 
(contact the administrative node at the address at the 
end of this document), which will give specific details of 
how to obtain access to the ADS System. Generally a 
user will be assigned to one of the ADS Primary Nodes 
for user support. 

It is assumed that the user is a novice and is try- 
ing to do a very simple, well-defined task but one which 
requires access to multiple astrophysics data centers and 
their on-line databases. In this scenario, the user will 
locate and subset two independent datasets and then in- 
tercompare the results. Specifically, the problem is to 
correlate measurements of galaxies which have been ob- 
served to have both a significant infrared flux (indicative 
of a large amount of cold dust), and an X-ray or ultravi- 
olet flux (indicative of hot gas). 

The user first asks about the existence of 100 pm 
(infrared) data, and ultimately finds his/her way to the 
IRAS Point Source Catalog. This user then wants to know 
if a subset of IRAS sources (e.g. galaxies that lie above 
30 degrees galactic latitude with 100 pm flux greater 
than 10 Janskys and 60/100 pm flux ratios indicative of 
temperatures less than 40K) have been observed in the 
X-ray (Einstein Catalog). 

Further, for those sources which were observed both 
in the infrared and with Einstein list the ones detected in 
IR and X-ray and plot the IR flux versus the X-ray flux 
for these objects. 

The specific steps are outlined below: 

Locating Infrared Datasets 

If we consider all the datasets potentially available in 
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astrophysics (not just the ‘standard’ products of NASA 
missions), the potential size and diversity of these datasets 
become quite large. Without data location tools, locating 
the correct dsitaset for our investigation would be at least 
as difficult, if not more so, than the processing we will do 
once the data is found. In most cases accessing this data 
would be much more difficult than processing it. 

One of the primary services of the initial ADS im- 
plementation is the factor space documentation location 
method described above. With this we can pose a factor 
space query of the type “I am interested in long wave- 
length infrared measurements of galaxies, particularly 100 
pm measurements, in the form of catalogs. Color tem- 
peratures, specifically ones derived from long wavelength 
measurements, will be correlated with X-ray data to try 
and determine the relationship between cold dust emis- 
sion and that from hot gas”. 

The factor space query will return a list of docu- 
ments, some of which might be journal articles about sim- 
ilar research, some descriptions of catalogs or other data 
(e.g., images), some mission descriptions, etc. Somewhere 
near the top of this list is likely to be the description of 
the IRAS Point Source Catalog. Unless we have been 
distracted by some of the other documents, we will read 
this and decide that this catalog is indeed what we want 
for our IR data. By poking around the documentation re- 
lated to this catalog (a simple browse mechanism through 
our documentation) we also determine what fields in the 
catalog are important for our investigation. 

The documents used in the search are maintained at 
the same institutions that bear responsibility for the data 
itself. 

Locating the X-ray Datasets 

The X-ra.y data (in particular the Einstein database) 
would be found the same way. One of the rules of the ADS 
is that catalog datasets are not made accessible through 
the system until appropriate documentation is also on- 
line. 

Extracting the IR Data 

We have determined the correct catalog and even 
have some idea as to which fields are appropriate for our 
endeavor. The next step is to actually query the database 
where the data resides and get our subset. The basis for 
such queries is SQL, as described in the section on our 
DIAM (DAVID). Our query wiE look something like: 

select * from iraspsc where fluxl00>10 and 
fiux60<fluxl00 and (glat>30 or glat<-30) 

In addition to a direct SQL query capability, ADS 
provides a more intuitive query by example (QBE) mech- 
anism where the user puts constraint information (Erectly 
into a template of the catalog in question. 

The infrared data of interest is located at the Infrared 
Processing and Analysis Center at the California Institute 
of Technology in Pasadena, California on a CDC Cyber 
mainframe in. the IM/DM database. 


Extracting the relevant X-ray Data 

To compare sources which both have an X-ray flux 
in the Einstein catalog and correspond to the sources ob- 
tained from our infrared query, requires the use of SQL 
for a database join. This is complicated somewhat by the 
need to potentially transform coordinates from one sys- 
tem or representation and then to perform the join based 
on spherical distance proximity. This process can also be 
performed using SQL directly or through the QBE mech- 
anism described above. 

Selection of the data must be done at the site where 
the data resides. However, the join process can be done 
at either data site or at the user’s local site. Optimiza- 
tion can be done to try and minimize the amount of data 
transfer but in practice the user usually wants to see the 
results of the two ‘selects’ before joining them and there- 
fore will transfer the data to the local site anyway. 

The X-ray data will be at the Harvard-Smithsonian 
Astrophysical Observatory in Cambridge, Massachusetts 
in INGRES on a SUN workstation. 

Comparison of IR and X-ray Data 

Once the join has been completed, the result is a 
single table in which are combined IR and X-ray mea- 
surements. Proximity on the sky was the deciding factor 
in matching sources and so we may well want to edit this 
table in a spreadsheet manner before proceeding. The fi- 
nal step in this example is simply to plot one column in 
this table versus another. 

Table processing and plotting will be performed lo- 
cally to the user. 

System Management Summary 

The ADS Program is currently managed from the 
Science Operations Branch, Astrophysics Division, NASA 
Headquarters, Washington, D.C. under Guenter Riegler. 
The ADS Project has been established at the Infrared 
Processing and Analysis Center which has also been des- 
ignated as the ADS Administrative Node. Dr. John Good 
is the ADS Project Manager and is responsible for the ac- 
tivities of the Administrative Node. 

Management of the overall ADS effort includes Sys- 
tem Development, System Oversight, and System Admin- 
istration. What foUows is a summary of the more detailed 
material documented in the ADS Management Plan. 

System Development 

The design of the ADS is motivated by the fact that 
it exists in a dynamic science and information system en- 
vironment, and therefore it must be a dynamic system. 
Thus, even as the ADS is released, development contin- 
ues on Core Services, User Services, Network Connectiv- 
ity, and the addition of new nodes. System Management 
is responsible for technical oversight of prototyping re- 
search, selection criteria, development of standards and 
conventions, and aU aspects of systems integration, test, 
and operation of new or revised ADS services. 
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System Oversight and Review Process 


To date, oversight of ADS development has been pro- 
vided by the ADS Working Group, under the leadership 
of James Weiss and John Nousek. When ADS becomes 
operational (and new nodes and sites are added to the 
system), the operation and continued development of the 
ADS will be overseen from both a users’ and a systems 
perspective by an anticipated hierarchy of committees. 
» committees will review all proposals for ADS de- 
velopment, and will integrate, prioritize, and make policy 
recommendations on all aspects of the ADS Program. 

The Science Operation/Management Operations 
Working Group (SOMOWG) has the highest oversight 
and review responsibility. As a matter of policy, the 
Science Operations Branch will make final selection of 
new ADS services, based on the results of the proposal 
and peer review process. For this purpose, an annual 
NASA Research Announcement (NRA) for the Astro- 
physics Software and Research Aids (ASRA) Program will 
be issued. 


System Administration 

The administration of the Astrophysics Data System 
is shared by NASA Headquarters, Astrophysics Division 
(Programmatic), the ADS Project Office/ADS Adminis- 
trative Node (Project), and the other primary nodes mak- 
ing up the ADS. The organizational structure, and defined 
roles and responsibilities are documented in Appendix A 
and the text of the ADS Management Plan, and in the 
ADS Primary Node Compatibility Requirements. 

. Development responsibilities include administration 
of both in-house and external service development con- 
tracts, certification of software, and software licensing. 

Operations Responsibilities include administration of 
maintenance contracts, system monitoring, system change 
control, and maintenance of system documentation. 

In addition, the administration' and coordination of 
all aspects of the review processes relevant to the ADS 
are the responsibility of the System Administration. 

Further information on the ADS can be obtained by 
contacting Dr. Good at 

Internet jcg@ipac.caltech.edu 
BITnet jcg%ipac@HAMLET.BitNet 
Telemail [JGOOD/NASAJNASAMAIL/USA 
uucp (cit-vax,trwrb!csula-ps)!ipac!jcg 

SPAN ROMEO::“jcg%ipac” 

TEL: (818) 584-2939 
FAX: (818) 584-9945 

The work described in this paper was supported by 
the Jet Propulsion Laboratory, California Institute of 
Technology, under the sponsorship of the Astrophysics 
Division of NASA’s Office of Space Science and Appli- 
cations. 
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1ST0RY: 

- Use Of Modems Denied, 1982 

- Astronet Project, 1985 

- Internet Link @ 56Kb, 1986 

(NOAO & NRAO Supported @ 9.6Kb) 

- SPAN Link @ 9.6Kb, 1986 

- Dual Protocol Proteon, 1989 @ 56Kb 

- T1 Link, 1991 


USES OF NETWORKS @ STSC1I 

General Communication 

National & International User Community 
All Protocols (Bitnet, Internet, Decnet, X.25) 
Science Collaboration 

Functional Activities 

Distributed Development (TRW & ST-ECF) 
Proposal Submission 
Internal Data Management 

Heterogeneous Environment 
Science & Operational Uses 
External Data Access 

Remote Catalog Access DMF 
[-- ADS Integration] 

F— DADS Futures! 
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DMF ACCESS 
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FUTURE USES 

Catalog Browse 

- Direct access 

- Via ADS 

Archive Browse 

- Via ADS 

- DADS 


Multidisciplinary Analyses 

- Different wavelengths 

- Different data types 


REQUIREMENTS 

Modest Bandwidth 
(56Kb) 

High Bandwidth 
(T1,TB) 

Image Compression 

Common Protocols & 
Interfaces 

Data Interchange Standards 
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DMF ACCESS 



Expectation: ADS & NREN functionality will be crucial to success of these systems 
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THE EARTH ENCOUNTER 


PRESENTED TO THE NSIUWG 


Theodore C. Clarke 
February 13, 1991 
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LUNAR SCIENCE OBJECTIVES 


• MARE ORIENTALS: COMPOSITION AND MULTISPECTRAL 

CHARACTERIZATION; SAMPLE DEEP LUNAR INTERIOR; 
IMPACT PROCESS STUDIES (SSI, NIMS, UVS, PPR) 

• LUNAR FARSIDE COVERAGE: ILLUMINATED AND DARKSIDE 
COMPOSITION AND MULTISPECTRAL CHARACTERIZATION; 
NEARSIDE/FARSIDE ASYMMETRIES IN THE LUNAR 
MARIA, HIGHLANDS AND PLAINS (SSI, NIMS, UVS, PPR) 

• MAP THE UNMAPPED LUNAR SOUTH POLAR REGION - 
~ 105°W LONG, 50°S LATITUDE TO SOUTH POLE 

(SSI, NIMS, UVS, PPR) 

• MAP LUNAR NORTH POLE; SEARCH FOR H 2 O IN 
PERMANENTLY SHADED CRATERS (SSI, NIMS, UVS, PPR) 

• SEARCH FOR HYDRATED MATERIAL ON THE MOON (NIMS) 

• RADIOMETRIC BRIGHTNESS vs. WAVELENGTH AND 
POSITION ON LUNAR DISC FOR TOPOGRAPHIC 
CHARACTERIZATION AND CALIBRATION AGAINST 
SIMILAR OBSERVATIONS ON THE -JOVIAN SATELLITES 
(PPR, NIMS) 
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EARTH SCIENCE OBJECTIVES 


• GLOBAL MAPPING OF MESOSPHERIC WATER AND 
MESOSPHERIC CARBON DIOXIDE (NIMS) 

• GLOBAL MAPPING OF METHANE AND OTHER 
"GREENHOUSE" GASES (NIMS) 

• CHARACTERIZE DYNAMICS OF THE PLASMA 
ENVIRONMENT IN THE EARTH'S MAGNETOSPHERE 
AND MAGNETOTAIL (F&P) 

• GROUND TRUTH SPATIAL RESOLUTION AND SPECTRAL 
MEASUREMENTS OF EARTH FEATURES FOR 
COMPARISON WITH OBSERVATIONS OF ASTEROIDS 
AND JOVIAN SATELLITES (SSI, NIMS) 

• CHARACTERIZE HYDROGEN GEOTAIL (UVS) 

• EARTH ATMOSPHERE AIRGLOW STUDIES (UVS) 

• MEASURE MASS OF THE EARTH (RS) 

• EARTH/MOON SYSTEM MOVIE, INBOUND TRAJECTORY 
LEG (SSI) 

» 5 DAY EARTH ROTATION MOVIE, OUTBOUND 
TRAJECTORY LEG (SSI, NIMS, UVS, PPR) 



SANTA 2 DATA FLOW 


Bridge programmed to 
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THE U.S./CANADA CONNECTIONS 
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THE EUROPEAN CONNECTIONS 





241 









243 




244 


ORIGINAL PAGE 

SLACK AND WHITE PHOTOGRAPH 





LIGHTNING WHISTLERS 



BLACK 


ORIGINAL PAGE 

AND WHITE PHO' 


'OGR4F 


H 


246 


60 sec 
TIME 



247 


ULTRAVIOLET SPECTROMETER OBSERVATIONS 
DURING CLOSE ENCOUNTER PERIODS 


• H GEOTAIL 

• INTERACTION 

OF SOLAR WIND 
WITH H AT THE 
MOON ll 2 

• COMETESIMAL 
CAUSED H 2 0 
CLOUD DIFFUSING 
FROM THE MOON 

• ANTI-TAIL 



WATER CLOUD 
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PHASE ANGLE AND CONE ANGLE OF THE 

EARTH DURING THE EARTH ENCOUNTERS 



© DARKSIDE (HIGH PHASE ANGLE) APPROACH 

• TERMINATOR CROSSING AT CLOSEST APPROACH 

• LIGHTS1DE (LOW PHASE ANGLE) DEPARTURE 

• CLOSING RATE ~ 750,000 KM/DAY 

® SUN POINTED SPACECRAFT REQUIRES USE OF LOW GAIN ANTENNAS 
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MOON IMAGING - EGA 1 



ORIENTALE 

UNMAPPED 

LUNAR 

SURFACE 






This image of the western hemisphere of the Moon was taken through a green filter by the Galileo spacecraft at 9:35 
a.m. PST Dec. 9 at a range of about 350,000 miles. In the center is the Orientate Basin, 600 mites in diameter, formed 
about 3.8 billion years ago by the impact of an asteroid-size body. Orientate* s dark center is a small mare. To the right 
is the lunar near side with the great, dark Oceanus Procellarum above and the small, circular, dark Mare Humorum 
below. Maria are broad plains formed mostly over 3 billion years ago as vast basaltic lava flows. To the left is the lunar 
far side with fewer maria, but, at lower left, the South-Pole-Aitken basin, about 1 200 miles in diameter, which resembles 
Orientate but is much older and more weathered and battered by cratering. The intervening cratered highlands of both 
sides, as well as the maria, are dotted with bright, young craters. This image was “reprojected” so as to center the 
Orientate Basin, and was filtered to enhance the visibility of small features. The digital image processing was done by 
DLR, the German Aerospace Research Establishment near Munich, an international collaborator in the Galileo mission. 
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X .5! 

H ' ’ 1 hese pictures of the Moon were taken by the Galileo spacecraft at (right photo) 6:47 p.m. PST Dec 8, 1990 from a distance of almost 220,000 miles, 

-T! T and at (left photo) 9:35 a.m, PST Dec 9, 1990 at a range of more than 350,000 miles. The picture on the right shows the dark Oceanus Procellarum in 

r, y the upper center, with Mare Imbrium above it and the smaller circular Mare Humorum below. The Orientale Basin, with a small mare in its center, is on 

i'l — the lower left near the limb or edge. Between stretches the cratered highland terrain, with scattered bright young craters on highlands and maria alike. 

CT The picture at left shows the globe of the Moon rotated, putting Mare Imbrium on the eastern limb and moving the Orientate Basin almost to the center. 

% The extent of the cratered highlands on the far side is very apparent. At lower left, near the limb, is the South-Pole-Aitken basin, similar to Orientate but 

r* very much older and some 1 ,200 mites in diameter. This feature was previously known as a large depression in the southern far side; this image shows 

r; its Orientale-like structure and darkness relative to surrounding highlands. 




254 


EARTH 1 FLYBY GEOMETRY 


NORTH POLE 




This color picture of Antarctica is one part of a mosaic of pictures 
covering the entire polar continent taken during the hours following 
Galileo’s historic first encounter with its home planet. The view shows 
the Ross Ice Shelf to the right and its border with the sea. An occasional 
mountain can be seen poking through the ice near the McMurdo Station. 
It is late spring in Antarctica, so the sun never sets on the frigid, 
icy continent. This picture was taken about 6:20 p.m. PST on December 
8, 1990. From top to bottom, the frame looks across about half of 
Antarctica. 
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E. Networking Subgroup Presentations 
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NASA/ SPAN AND DOE/ESNET-DECNET TRANSITION STRATEGY 
FOR DECNET OSI/ PHASE V 


Linda Porter, NASA/Marshall Space Flight Center 
Phil DeMar, DOE/Fermi National Accelerator Laboratories 
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ABSTRACT 

This paper examines the technical issues involved with the 
transition of very large DECnet networks from DECnet Phase IV 
protocols to DECnet OSI/Phase V protocols. The networks involved 
are the National Aeronautics and Space Administration's Science 
Internet (NSI-DECnet) and the Department Of Energy's (DOE's) Energy 
Sciences network (ESnet -DECnet) . These networks, along with the 
many universities and research institutions connected to them, 
combine to form a single DECnet network containing more than 20,000 
nodes and crossing numerous organizational boundaries. The 
transition planning for this network must deal with both the scale 
of the network and its administrative complexity. This necessitates 
creation of a transition strategy that is flexible enough to allow 
different parts of the network to upgrade to Phase V at different 
times, yet is sufficiently coordinated so that network functions are 
not disrupted. 

Discussion of transition planning, including decisions about 
Phase V naming, addressing, and routing are presented. Also 
discussed are transition issues related to the use of non-DEC routers 
in the network. 


INTRODUCTION 

The DECnet Internet is a very large DECnet-based network 
reaching government, university and research sites throughout the 
world which are involved in scientific research. The network has 
grown from numerous small, disconnected DECnet networks of 10 years 
ago to a conglomerate network which crosses numerous international 
and organizational boundaries. The DECnet Internet, therefore, is 
not an "engineered" network, rather, it is the result of the growth 
and interconnection between a number of smaller, previously 
independent DECnet networks. 

The four largest participants in the DECnet Internet are the 
NSI-DECnet (formerly SPAN), the ESnet-DECnet , the European Space 
Agency's Space Physics Analysis Network (E-SPAN) and the consortium 
of European High-Energy Physics Research Institutions (E-HEPnet). 
Other participants include scientific DECnet networks in Japan, 
Canada, South America, and Australia. Administratively separate, 
these DECnet networks share a common address space and lie within a 
single routing domain. The result is a single huge DECnet network of 
thousands of nodes, complicated architecture and many network 
managers . 
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In the U.S., the NSI-DECnet and the ESnet-DECnet comprise the 
bulk of the DECnet Internet systems: 

o The NSI-DECnet Is a NASA-funded network supporting space plasma 
physics and astrophysics as well as related space science research 
programs. NSI-DECnet reaches more than 80 sites, including most 
of the NASA field centers and universities that are involved In 
NASA research programs. The network also has connections 
to other DECnet networks throughout the world that engage in 
space science research and programs (Figure 1). 

o The ESnet-DECnet is a DOE-funded network supporting energy 
research programs such as high energy physics, nuclear physics, 
and fusion research. It connects together over 60 sites in the 
United States, Including the major national laboratories, as well 
as universities involved in energy research programs. The 
ESnet-DECnet, like the NSI-DECnet, supports numerous connections 
to other DECnet networks around the world involved in energy 
research (Figure 2). 

The network management teams for the four major participant 
networks coordinate operations through the "HEP-SPAN DECnet 
Coordinating Group", or HSDCG , to ensure the network functions 
properly. The HSDCG is involved in coordinating technical issues 
such as address usage and circuit cost assignments (routing), as well 
as administrative issues such as security incident handling and 
network information distribution. The primary task now facing the 
group is planning for the transition of DECnet Phase IV protocols in 
use on the network today to DECnet OSI/Phase V. 

Complicating the planning for implementing Phase V on the DECnet 
Internet are the numerous interconnections (dashed lines) between the 
networks (Figure 3). These interconections were originally installed 
to serve specific program or research requirements rather than 
improve overall network performance. There are no less than 17 
interconnections between NSI-DECnet and ESnet-DECnet in the U.S. 
Although these links provide redundancy, they also add many routers 
to the network, making the routing topology very complicated and the 
transition planning more difficult. As we'll see later on, routers 
are key elements in the transition. 

This paper deals with the major issues involved in planning for 
the transition to DECnet OSI/Phase V, primarily from the perspective 
of the NSI-DECnet and ESnet-DECnet networks. First we examine the 
motivations behind the requirement to use Phase V protocols. Next we 
present constraints on the transition planning, including a 
discussion on maintaining Phase IV connectivity and Implementing OSI 
protocols for the anticipated future network environment. We then 
outline the general transition strategy for the DECnet Internet . 
Finally, we present a technical discussion of OSI/Phase V 
addressing, naming and routing issues. 
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WHY DO WE NEED TO UPGRADE TO PHASE V? 

The driving force for an early transition to DECnet Phase V is 
the fact that the DECnet Internet has reached the practical 
addressing and routing limits of DECnet Phase IV. Also, DECnet 
Phase V promises integrated support for OSI, which is expected to he 
the protocol of choice for the "future. Finally, the U . S . Government, 
through its Government OSI Profile (GQSIP) procurement policies will 
require its networked systems to support the OSI protocols. 

PHASE IV ADDRESSING LIMITATIONS 

DECnet Phase IV allows only 2 bytes for a node address, which 
is further divided into 33 areas. The DECnet Internet, which 
consists of numerous networks and hundreds of sites in many 
countries, cannot meet its addressing requirements with only 63 
DECnet areas. For example, it is very difficult to inform sites in 
different countries, used to their own autonomy, that they need to 
share the same DECnet area and coordinate their address assignment 
policies. In addition, the cost of routing packets over the public 
switched facilities for European sites is staggering when sites 
share a single DECnet area and face charges for routine exchange of 
voluminous intra-area routing information. 

Various area filtering techniques have been utilised to deal 
with the limited address space. These area filtering techniques have 
created "hidden" areas. Hidden areas are defined as those areas 
which are intentionally invisible to most of the network. As a 
consequence, certain area numbers can be duplicated without impact on 
normal network operations. These hidden areas, however, make network 
management difficult, and can break the network if the filtering 
mechanism is accidently removed. 

DECnet QSI/Phase V provides 20 bytes of address space, obviously 
solving the limitations of Phase IV addressing. Just how big is 20 
bytes? Veil, it's probably enough to assign every toaster (5 billion 
per planet) on every planet In the universe (about 10E+22) with about 
20 quadrillion addresses (a 2 followed by 16 zeros). Although not 
quite infinity, 20 bytes will probably cover addressing requirements 
until we retire. 


PHASE IV ROUTING PROBLEMS 

While Phase IV address space is bounded, Phase IV routing Is 
boundless. This means the entire network is contained within a 
single routing domain, creating a number of problems: 

o The network is very vulnerable to inadvertent connections that 
bring duplicate area numbers into the network which, unlike hidden 
areas, are very visible. Visible duplicate area numbers cause 
network partitioning. In a partitioned network, parts of the 
network cannot exchange messages with other parts of the network. 
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o With a heavily interconnected topology using a single routing 
protocol, derivation of appropriate DECnet circuit costs for 
achieving proper traffic flow becomes very complex and very 

difficult . 

o The numerous routing loops in the network often cause unexpected 
and inappropriate routing during periods of circuit instability. 
This causes poor performance, or in some cases, prevents packets 
from reselling their destination. Routing loops are a consequence 
of the failure of the Phase IV distance vector routing algorithm 
when used in a large network with a complex topology, like the 
DECnet Internet . 

DECnet OSI/Phase V provides definable routing domain boundaries 
and the ability to control what routing information is propagated 
into or out of any particular network. With such control, 
inadvertent connections are harder to make, and ease problems of 

duplicated areas. 

Also, the Phase V link state routing algorithm is much more 
robust and scalable than the Phase IV distance vector algorithm, and 
it eliminates the Phase IV routing loop problems. 


THE TREND TOWARD OPEN NETWORKING PROTOCOLS AND U.S. GOSIP 

It is generally accepted that most institutions will use OSI 
protocols eventually. The International Standards Organization (ISO) 
is driving the development of OSI protocols for the purpose of 
providing worldwide computer interoperability. 

DECnet OSI/Phase V implements OSI protocols while preserving 
interoperability with DECnet Phase IV systems. No other protocol 
can provide for a relatively transparent transition from DECnet 
Phase IV to OSI (or other) protocols. 

Also, the U.S. government mandates specification of OSI for 
networked systems in purchases. These practices are defined in the 
Government Open Systems Interconnect Profile (GOSIP) procurement 
specification (Federal Information Processing Standard 146) . GOSIP 
also describes the OSI protocols to be used, and their formats. The 
intent is to eventually make all networked Government systems use 
OSI , resulting in greater interoperability and hence less reliance on 
any particular computer or network vendor. A significant portion of 
the network, therefore, will be required to support OSI. 


CONSTRAINTS ON PHASE V TRANSITION PLANNING 

There are several constraints affecting the development of the 

transition plan: 
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o Backwards compatibility with the existing Phase IV production 
network must be maintained throughout the transition. 

The transition to Phase V will take an extended period of time, 
probably requiring several years. During the transition period, 
Phase IV systems throughout the network must maintain full 
connectivity with other Phase IV systems and also Phase V systems. 
In addition, the area filter mechanisms presently used in the 
Phase IV network must remain until they are either no longer 
necessary or they can be removed without disrupting the network. 

o Technical constraints on the use of OSI addressing throughout the 
transition must be understood. 

Because backwards compatibility with Phase IV systems must be 
maintained, networks are constrained to use Phase IV compatible 
addresses for Phase V systems during the transition period. Well, 
it's not surprising the number of Phase IV compatible addresses is 
identically equal to the number of Phase IV addresses -- we still 
only get to use 2 bytes! The address management and assignment 
practices presently enforced in the Phase IV network will 
necessarily remain for assignment of Phase IV compatible addresses 
during the transition process. However, some systems will be 
identified as not requiring communication to Phase IV systems 
during the transition. These may implement their facility- 
assigned OSI addresses, but not a Phase IV compatible address. 
After the transition, sole use of the facility-assigned 
OSI address for all systems will be encouraged. 

o Technical constraints on the use of OSI routing throughout the 
transition must be understood. 

Phase V allows only one routing algorithm (Phase V or Phase IV) 
within a specific DECnet area. This means that *all* routers 
within an area must be able to support Phase V before that 
particular area can be upgraded. Host-based (VMS) routers 
present another problem. They will never be able to support the 
Phase V Level-2 (area) routing, and will probably be somewhat 
delayed in supporting Phase V Level-1 (intra-area) routing. Note 
that VMS routers used only for cluster aliasing are not affected. 
However, facilities using VMS routers for other than cluster 
aliasing are likely to be severely constrained in efforts to 
upgrade to Phase V. These sites will be encouraged to move from 
host-based routers to dedicated routers. 

o The variety of hardware and software in use affects the timing of 
implementation . 

Allowances for the variety of routers and systems in use in the 
DECnet Internet must be made in the transition plans. While some 
parts of the network contain only DEC hardware and software, other 
parts depend on third-party implementations of DECnet. The 
planning and timescale for the transition of the latter will 
almost certainly be different than the former. 
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o The transition must be implemented in a manner consistent with 
the long term objective of being part of a global OSI network. 

The new protocols implemented, must conform to existing OSI 
recommendations and specifications. For government sites, GOSIP 
address formats as well as agency GOSIP transition plans need to 
be followed. The namespace will be structured to follow the OSI 
X.50G recommendations, and planned with the idea of becoming part 
of a global X.500 directory service when that becomes available. 

Routing under OSI must be planned and eventual implementation of 
"routing domains" consistent with local facility plans must be 

permitted. 

o The organizational complexity of the existing global internet 
must be considered. 

The DECnet Internet crosses national boundaries as well as agency 
and facility jurisdictions. Therefore, the transition plan must 
be flexible enough to meet the differing needs and perspectives 
of individual facilities and agencies. A top-down approach using 
a "one strategy fits all" philosophy is very likely to fail 
miserably. 


PHASE V TRANSITION GENERAL STRATEGY 

Considering the goals and constraints of the transition, the 
general strategy for the transition of the DECnet Internet to 
OSI/Phase V will be based on the following: 

o Network backbones are expected to be upgraded to Phase V at the 
earliest possible time. The underlying philosophy will be 
"backbone sites first, tail sites last". This provides two 
things: 1) a central framework around which to base the 
transition, and 2) upgrade of the major resources on the network 
at an early time in the transition (since they tend to be located 
at backbone sites). 

o Detailed transition plans for individual networks will generally 
be ba,sed on an area-by-area upgrade - an incremental strategy. 
Phase IV areas within the DECnet Internet that are ready to 
upgrade will be identified. These areas will then coordinate a 
changeover to the use of Phase V protocols all at once. This is 
not quite as impossible as it sounds, because the primary issue in 
this changeover is upgrading the * routing* nodes in an area. End 
systems may run either Phase IV or Phase V software in either a 
Phase IV or Phase V area. End systems can be upgraded gradually 
throughout the transition process. 

Two stpproaches are possible with an area-by-area transition. The 
first, approach identifes the sites within an area ready to upgrade 
to Phase V. Sites sharing that area which are unprepared or 
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unable to go to Phase V will be assigned new Phase IV addresses 
and moved, allowing the remaining the sites to proceed with Phase 
V implementation. 

The second approach again starts with identifying sites within an 
area ready to upgrade to Phase V. This time, though, those sites 
ready to upgrade will first adopt new Phase IV addresses, thus 
decoupling them from sites not ready to upgrade. Then the sites 
with the new addresses will coordinate a changeover to Phase V 
routing protocols all at once. In some cases, the adoption of new 
Phase IV compatible address and the changeover to Phase V routing 
protocols will happen simultaneously. 

It is likely that certain areas will remain permanent Phase IV 
areas to support those systems which will never run OSI 
protocols . 

This incremental strategy provides a means of accelerating the 
transition process for those portions of the network ready to 
upgrade. It also provides justification (and motivation) for 
other sites to hasten their own OSI/Phase V Implementations. 

o Phase IV backwards compatibility will be preserved by adoption 
of a common high-order address, or "Phase IV prefix" for all the 
networks within the DECnet Internet. The common Phase IV prefix 
will be used to create a virtual routing domain for the Phase IV 
nodes within the network, preserving the Phase IV address 
structure. Phase V systems will be multihomed (have multiple 
addresses) when necessary. On a multihomed system, one address 
will be the Phase IV compatible address (common Phase IV prefix + 
existing Phase IV DECnet address) . The other address will be the 
facility assigned OSI address. Addressing is further discussed in 
the next section. 

o There will be a single namespace created to support the Phase V 
network. Namespace name and structure will be common, and 
implementation will adhere to guidelines. Directory replication 
and access, as well as clearinghouse location, will be tightly 
controlled down to the facility level. The namespace 
Implementation will precede Phase V implementation, and sites will 
be allowed (encouraged) to utilize the namespace for existing 
Phase IV applications. Namespace issues are discussed in greater 
detail in the next section. 

o Initially, the number of routing domains in the changing network 
will be minimized. As the transition progresses, implementation 
of routing domains will increase. However, there are technical 
reasons which prevent initial widespread use of roxitlng domains. 
These reasons are presented in the next section. 

o There will be a finite amount of time for completion of the 

transition across the entire network. After that time ends, the 
network will be declared a Phase V network, and use of extended 
address space will be encouraged. Phase IV areas (and Phase IV 
end systems within Phase V areas) may remain after this time, but 
direct access to wide-area network resources no longer will be 
guaranteed. “Poor man's routing" may be required to provide 
access for those systems. 
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o ESnet-DECnet , NSI-DECnet, E-HEPnet, E-SPAN, and other network 
management teams controlling specific parts of the DECnet 
Internet will each refine its own transition plan, using 
the transition strategy it deems appropriate for its own network 
environment . The time scale for each of these individual 
transition plans will be independent of the others. However, 
transition strategies and implementation plans will be closely 
coordinated with other member networks . 


TECHNICAL ISSUES FOR DECNET INTERNET TRANSITION PLANNING 

The groundwork for understanding the existing network 
environment, the need for a transition, and the general strategy for 
the transition has been discussed. The following sections tackle 
addressing, naming, and routing issues in greater technical detail. 

ADDRESSING 

The OSI address format to be used by all U.S. Government 
Institutions is defined by GOSIP. The proper name for this address 


format is the "Network Service Access Point", or NSAP. The NSAP is 
20 bytes long and is shown in Figure 4. 

< IDP > < DSP 

< HO-DSP > < -LA- > < ID > < -SEL- > 

AFI 1 IDX I DFI I AA I RESV I SNID I AREA I END SYSTEM I NSEL I 

121 32226 1 bytes 

4? 0005 SO 0000 nnnn mmmm abcdefghijkl yy 

003400 (NASA) 

000400 (DOE) 


IDP : Initial Domain Part AFI : Authority and Format 

DSP : Domain Specific Part Identifier 

HO-DSP : High Order Domain Specific Part IDI : Initial Domain Identifier 
LA : Local Area DFI : Data Format Identifier 

ID : end system IDentification AA : Administration Authority 

SEL : transport SELector byte SNID : Sub-Network ID 


FIGURE 4. - THE GOSIP NSAP 

GOSIP defines values for the IDP and the DFI. NASA and DOE 
have applied to the National Institute of Standards and Technology 
for the value of the "AA" field, and it has been assigned: NASA 
will use “ 003400" and DOE will use “000400", as shown in Figure 4. 
The remainder of the address will be assigned according to internal 
NASA and DOE recommendations. 
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AN ADDRESSING PROBLEM 


An address field of great interest is defined by the combination 
of tbe IDP and HO-DSP fields, or the : 'high-order address". To 
explain this, a small digression is needed. 

PHASE V TRANSITION RULE: Phase IV systems can communicate 
only with s37stems having the same high-order address as 
the Phase V routers to which they are connected. 

That is, the portion of the address to the left of the local 
Area i. LA) field must be identical on all Phase V systems if Phase IV 
end systems are to communicate during the transition. The reason for 
this is simple: Phase IV systems have no knowledge or ability to 
generate any address but a Phase IV style address containing an area 
between 1 and 63 and a node address between 1 and 1023. However, in 
a Phase V network, Phase IV end-systems actually are assigned a 
high-order address: it is the high-crder address of the Phase V 
router to which the Phase IV system is connected. But because a 
Phase IV system itself has no knowledge of' its high-order address, it 
can't generate a different one. Therefore, a Phase IV system can 
talk only to those systems that are connected to a router with the 
same high-order address as the Phase V router that is connected to 
the Phase IV system. 

Therefore, the statement of the problem is: 

If all institutions adopt the OSI address format with 
arbitrary high-order addresses, how can Phase IV system 
connectivity be maintained? 


THE ANSWER 

OSI specifies support for multiple addresses for a single 
system. A system with multiple addresses is said to be ’multihomed" . 
If one of the addresses on a Phase V multihomed system contains a 
prefix common to all other Phase v nodes, then Phase IV connectivity 
can be preserved. The form of this address is described in Figure 5. 

< -IDP- > < HO-DSP > < THE REST 


i zz i pppp I AREA I END SYSTEM I NSEL 


< Phase IV prefix > 2 6 1 

FIGURE 5. - PHASE V/PHASE IV COMPATIBLE ADDRESS FORMAT 

This common address can be up to 20 bytes long, and conforms to 
OSI Standards. (Note that the "AREA: END SYSTEM” must translate to a 
Phase IV compatible address, i.e. area between 1 and 63, node 
address between 1 and 1023.) 
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Therefore, on® address on Phase V systems can be GOSIP (or ANSI 
or other standard) . The other address will be the address linking 
the Phase IV DECnet Internet . For example , a node using Phase IV 
compatible address 7.39 can have two completely Independent addresses 
as follows: 

1. GOSIP COMPLIANT ADDRESS: 


IDP 

1 HO-DSP 

1 LA 1 

1 ID 

1 SEL 

47 0005 

80 003400 0000 1100 

2366 

08Q02bl 23456 

yy 

PHASE IV/V COMPATIBILITY ADDRESS: 



< Phase IV Prefix 

> 



IDP 

1 HO-DSP 

1 LA 1 

1 ID 

1 SEL 


99 4242 0007 aa000400271C xx 


(The "99 4242" is a hypothetical example of a unique Phase IV 
prefix used in the DECnet Internet for the purpose of 
transition. ) 

Therefore, multihomed Phase V systems satisfy requirements 
for use of OSI while preserving Phase IV compatibility during the 
transition period. 

ADDRESSING AUTHORITY 

For the purpose of implementing a Phase IV to OSI/Phase V 
transition, the existing methods for obtaining 8 Phase IV* addresses 
will be unchanged throughout the Phase V transition period. Phase IV 
addresses will be used with the unique Phase IV prefix to ensure 
Phase IV/V transparency during the transition. As described above, 
however, the Phase. IV address is unrelated to the value of the 
facility-assigned OSI address. Sites can receive OSI addresses from 
their OSI Address Authority at any time (of course). 


NAMING ISSUES 

The directory and naming service that will be used during the 
transition is DEC'S "Digital Naming Service", or DECdns. DECdns 
provides, among other things, address-to-name and name-to-address 
translation services as well as user application and other general 
naming services. DECdns provides a robust method to keep names and 
addresses up to date, and a method for replicating portions of the 
namespace for redundancy. DECdns is expected to interoperate with 
the OSI 1.500 directory service when that becomes available. Network 
support for DECdns during the transition to DECnet OSI/Phase V is a 
requirement . 
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Tli 9 following definitions are important to understanding naming 
issues. 


Logical namespace - the global structure defining how systems 

are named. 

Physical namespace - the implementation in a working network 

of the Logical Namespace. 

Logical namespace Issues are separate from physical namespace issues , 
and are treated separately. 

LOGICAL NAMESPACE ISSUES 

The Logical namespace to be used for the DECnet Internet will 
adhere to OSI X.500 recommendations as closely as possible. It will 
also be kept as shallow as possible. The general structure of an 
X.500 name is: 


. COUNTRY . ORG . OS . . . 

where ORG is the organization "owning" this specific portion of 
the namespace, and OS is am “organizational specific" identifier 
assigned by the owning organization. 

NASA's current recommendation for the naming of NASA field 
centers is the following: 

. US . NASA . center . name 
e.g. 

. US . NASA . MSFC . SSL 

DOE's recommendation, and the one now being used in the OSI 
transition guidelines for that agency is the following: 

. US . facility . name or .US . DOE . facility . name 

e.g. (for small DOE sites) e.g. 

. US . FNAL . FNMFE . US . DOE . CHI . name 

We can draw three observations from these recommendations: 

1) This is backwards to the TCP/IP Internet standard - we don't love 
it, but if the names are to adhere to X.500 recommendations it 

is unavoidable that DECnet Phase V system names will be reversed 
with respect to TCP/IP Internet names. 

2) There is no upper-level domain as in the Internet standard, i.e. 
no "EDU" or "COM" field. The feeling is these fields do not 
convey useful meaning, and are contrary to the X.500 
recommendations . 
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3 ) DEC recommends against putting the country symbol in the 

DECdns namespace for a network. This is because most sites will 
be joining a larger network - and hence namespace - in the 
future, where the upper level directories are already provided. 
This is not suitable for the already international DECnet 
Internet , whore the country code must be present to distinguish 
international organizations. 

DOE and NASA are not naming authorities for Z.50Q (nobody is, 
yet!). However, they will recognize and register Internet Facility 
level domain names, such as "FNAL” , “UCSD" , and "MSFC" in the 
namespace for sites currently served by the DECnet Internet. 

The intent is to join the DECnet Internet namespace with the 
global Z.500 directory services when available. This will be done by 
removing the appropriate top level directories in the DECdns 
namespace and pointing the remainder at the Z.500 root. At that 
time, one presumes, a global naming authority and registration board 
will exist, and facilities will register with that organization. 

PHYSICAL NAMESPACE ISSUES 

Institutions such as major DOE sites and NASA field centers 
will emplace name servers. An invitation to Join the logical 
namespace structure provided by these name servers will be extended 
to associates. DEC (and we) recommend that there be at least two 
name servers per local area network. 

Each facility joining the namespace will be responsible for 
maintaining the master copy of its own top level (facility) directory 
at its local site, just as is presently the case for Internet 
(TCP/IP) domain name servers. However, read-only copies of facility 
level directories will likely be located elsewhere in the network as 
well . 


More work needs to be done in deciding guidelines for 
replication and access of the physical namespace across the DECnet 
Internet. (Replication assures reachability in case of a network 
link or server failure . ) 


ROUTING ISSUES 

INTER -DOMAIN VS. INTRA-DOMAIN ROUTING 

There is a lot of confusion about inter-domain and intra-domain 
routing. Many confuse dynamic and static routing issues, and others 
believe routing hierarchy is many levels deep (it's only two), and 
routing domains depend on specific fields of the NSAP (they don't). 
So, sit back, clear your mind, and let's start from scratch. 
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INTRA-DOMAIN ROUTING 

DECnet OSI/Phase V uses a protocol named. "IS-IS Routing Exchange 
Protocol" for intra-domain routing. (IS - Intermediate System, i.e. a 
router). This protocol is currently at draft international standard 
stage and will be a full OSI protocol probably within a few months. 
The IS-IS protocol uses a more robust and scalable routing algorithm 
than Phase IV called “Link-State Routing". However, the following 
analogy with DECnet Phase IV will be used to illustrate an important 
concept . 

Like DECnet Phase IV, IS-IS routing has two *and only two* 
routing levels: Level 1 and Level 2. There is no deeper hierarchical 
routing specified by this standard. An IS-IS Level 1 router keeps 
information on every end system in its area, like Phase IV DECnet. An 
IS-IS Level 2 router keeps information on every other area in the 
network, again, like Phase IV. 

Okay, so what is an OSI area? This is where the NSAP plays a 
role. The IS-IS standard routes area (Level-2) traffic based on 
the value of the IDP + HO-DSP + LA fields. Therefore, these fields 
define the OSI area, as shown in Figure 6. 


I IDP 


DSP 


HO-DSP 


LA 


ID 


SEL 


< LEVEL 2 ROUTING > 

< — LEVEL 1 ROUTING— > 

Figure 6. - IS-IS ROUTING AND THE NSAP 

Now, the amount of space allowed for areas is huge - up to 13 
bytes! Instead of being constrained by only 63 areas, an OSI network 
could wallow in 2.0E31 areas. One can immediately see both the 
advantages and problems associated with the possibility of tremendous 
numbers of OSI areas. 

INTER-DOMAIN ROUTING 

To prevent problems associated with zillions of areas (and 
for other reasons), network management can define "Routing Domains." 

ROUTING DOMAIN: A routing domain is a collection 

of systems that are told they are running the same 
routing protocol. 

A routing domain can be defined which allows all systems within 
it to keep their routing information confined, or better - everybody 
else's routing information out. Defining a routing domain can 
Isolate a group of areas from exchanging routing information with the 
rest of the world while allowing well-defined interconnection points 
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so that communications between routing domains is still possible. 
Defining a routing domain, then, can solve two problems. One, it can 
reduce the number of areas in a network, and two, it can protect a 
network from routing problems in a neighboring network. 

It's important to realize that the mechanism used to define a 
routing domain is not particularly related to any specific field in 
the NSAP prefix (the portion of the address above the LA field. 

Figure 4). There is no special field in the NSAP such that when 
bits in it are changed, the routing domain is changed as well. A 
routing domain boundary oan be set between any two sites whose NSAP 
prefixes are different. Conversely, a routing domain can contain 
multiple NSAP prefixes . 

DRAWBACKS TO ROUTING DOMAINS 

There are some drawbacks to setting up routing domains, 
especially when Phase IV to Phase V transition strategies are 

considered . 

First, there is no OSI standard for dynamic inter-domain 
routing. This protocol is under development and it will take many 
months, if not longer, before it will be available. For the present, 
then, all inter-domain routing is static, and must be manually 
configured and manually fixed if a line goes down. This means 
network managers (or their operators) are responsible for adding and 
deleting addresses from the address tables and fixing circuit 
problems - manually. The more connections a routing domain has, the 
more manually intensive maintenance and operations become. Compare 
this with DECnet Phase IV routing where the network automatically 
attempts to repair a circuit outage by using a fallback path if 
available, regardless of the complicated physical topology - even in 
the middle of the night ! 

A classic example of the headaches introduced by manual 
maintenance is shown in Figure 7, "The two-hop problem". In this 
simplified drawing', Routing Domains A, B, and C are connected in a 
line. Routing Domain A and C normally communicate through B using 
circuits q and y. Circuit m exists between A anc C as a backup. Now, 
assume circuit q fails. Routing domain A recognizes q has failed, 
and .begins to re-route its traffic destined for B and C over circuit 
m. So far, so good. To simplify this a little, let's look in 
particular at messages from A to C. A packet from A arrives in C 
over circuit m. C receives the packet and sends it to its 
destination in C. In response, the destination system tries to reply 
to the source system in A by sending a packet back into the network. 
However, because circuit q is not in C's routing domain, C has no 
knowledge of its failure. Therefore, C dutifully sends the reply 
packet to A ‘through circuit y* . B gets the packet and says "nope, I 
can't forward this, because circuit q is down" and sends it back to 
G. G gets the packet back, and again tries to send it to A ‘over 
circuit y* . C is really stupid about all this, but that's what 
static links can do to a network. C will never automatically 
re-route the packet over m, because C is never told that circuit q is 
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down and thus should readjust its own routing to compensate. The 
packet will bounce around between C and B until it reaches its 
maximum cost or visits, and then it disappears: this is the 
"black-hole** effect of static routing. To use circuit m, a network 
manager in C will have to manually adjust the circuit parameters. 

Second, network management cannot set a routing domain between 
two sites which use the same Phase IV area and must maintain Phase 
IV connectivity. This constraint is certainly the most restrictive 
for planning routing domain boundaries during the transition. 

CONSIDERATIONS FOR THE DECNET INTERNET 

Politics implies lots of routing domains. It is naive to assume 
that Individual facilities, when having the ability to shield their 
networks, will not take the opportunity to do so. In the long run, 
setting routing domain boundaries will provide a mechanism for 
protecting a network's routing functions from problems in a 
neighboring routing domain. This means routing domains undoubtedly 
will be implemented down to site level, eventually. 

However, prudence, responsive network routing, and preservation 
of Phase IV connectivity and network manager sanity indicate the 
network should support very few routing domains, at least at the 
start of the transition. It has been proposed that a logical place 
to set a routing domain boundary at the start of the transition 
would be across the Atlantic, between U.S. and European sites. 

So, it is clear that we must eventually allow for the existence 
of many routing domains, but it is also clear that we will divide 
the DECnet Internet into only a few, and possibly just two, routing 
domains at the start of the transition. Therefore, the global 
transition strategy must incorporate mechanisms for identifying 
logical placement of new routing domain boundaries and coordinating 
the setting of these boundaries throughout the transition process. 


SUMMARY 

The need for a Phase V/OSI transition is clear. The limits of 
DECnet Phase IV protocols have been reached, and the Government is 
requiring implementation of OSI protocols for Its agencies and 
departments. 

The major issues for moving the Phase IV network to OSI /Phase V 
are being tackled for the DECnet Internet by the HSDCG . The 
Implementation of addressing and naming are largely understood and 
accepted. A choice for the global "Phase IV prefix" still has to be 
made. The emplacement of physical name servers and the operation of 
the namespace in the Phase IV network is progressing. 

More work remains to be done in planning for the use of routing 
domains in the DECnet Internet during the transition. 
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The general strategy to move the DECnet Internet Phase IV 
network to a Phase V network is to use an area-by-area transition 
plan, starting with network backbones, while preserving Phase IV 
connectivity throughout transition. 

Detailed transition plans are being developed by the individual 
network participants taking into account the issues being coordinated 
by the HSDCG. 
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SECURITY SUB-GROUP 


Security - How and Whv 


GAO audit and report critical of NASA network management 

NASA image is Vulnerable - Any breach becomes a "NASA Problem" 

Security of the network requires adequate end-node security 

NSI cannot require compliance, but all policies and procedures will be consistent 
with NASA policy. No "extraordinary" measures will be required - however, 
common sense will. 

NSI will provide the user community with assistance and tools to allow 
non-interference management of tail sites. 


2/91 - 2 



NSI SECURITY 


TOOLKITS 

• Enable remote sites to self-evaluate their vulnerabilities 

• Working w/NIST to model threats and identify existing tools 

• Evaluating LLNL "SPP and CMU "COPS” packages 

• Priority being given to developing a set of UNIX tools 

• Will update and revise the VMS (SPAN) toolkit 

• Goal is VMS/UNIX equivalent fools 


NSI-Approved and NSI-Developed 
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SECURITY SUB-GROUP 


SECURITY POLICIES AND DOCUMENTATION 

Goal: To establish a network-wide "Security Baseline" 

All policy will be NHB 2410.9-compliant 

Will address UNIX & VMS, DECnet & TCP/IP (OSI as appropriate) 

Will reflect required Risk Analysis elements 

Will include Audit Trail guidance based on inputs from FBI and Justice Depts 
Currently in draft form - Expected to publish in FY90 

2/91 - 4 



287 


SECURITY SUB-GROUP 


RISK ANALYSIS & MANAGEMENT 

Government sites required to perform their own. NSI will provide guidance. 
NSI will do a "Network" Risk Analysis. 

NSI is working with Code NTD to develop a uniform NASA approach 
consistent with AIS guidelines. 


2/91 -5 



G. User Services and Applications Presentations 
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Requirements Management: A CSR’s Perspective 

Presentation to the NSIUWG User Services Subgroup 


Joanie Thompson 
Sterling Software, Inc. 
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Requirements Management: A CSR’s Perspective 


The goal of my presentation is to give the NSI User Services Subgroup an understanding of the 
Requirements Management process by describing the tools which the Customer Service Staff uses 
to manage the networking requirements. 

First off, take a quick look at the chart on the next page. Go ahead, then come back to this page. 
I’ll wait... 

The process is about as simple as it looks. :-) But have no fear, your Customer Service Represen- 
tative (CSR) understands the chart and knows how to navigate your networking requirements in- 
to and out-of all those boxes, diamonds and rectangles. 

To give you a better understanding of the process (sans chart), I have designed this presentation to 
be more of an "narration with pictures". There is a cover page which describes the tool and how 
it is employed by the CSR -- that is the "narration". The "picture" is the sample chart/letter/form 
which follows the narration page. 

Ready? Here we go.... 
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Customer Service Overview 
of Network Service Request Processing 
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Discipline Customer Service Representative Responsibility Matrix 


Get to know your CSR! If you or your project need a new network connection, an upgrade to your 
existing services or other network services the best place to start is with the CSR. 



Customer Service Representative Responsibility Matrix 


CODE 

DISCIPLINE 

CSR 

PHONE NUMBER AND EMAIL ACCESS 





sz 

Astrophysics 

Joanie Thompson 

J. Thompson, (415) 604-4550 

joanie@nsipo.nasa.gov 

AMES "joanie@ nsipo.nasa.gov" 

sc 

Communications 

Maria Gallagher 

M. Gallagher, (415) 962-7753 

maria@nsipo.nasa.gov 

AMES::”maria@nsipo.nasa.gov” 

SE 

Earth Science and 
Applications 

Kathy Bosovich 
Lenore Jackson 

K. Bosovich, (415) 604-5859 
bosco@nsipo.nasa.gov 

AMES : : "bosco@ nsipo .nasa.gov" 

L. Jackson, (301) 286-7251 
NSSDCA::JACKSON 
iackson@nssdca.Esfc.nasa.gov 

SM 

Flight Systems Division 

TBD 

Christine Falsetti 

C. Falsetti, (415) 604-6935 
falsetti@ nsipo. nasa.gov 
AMES::"falsetti@nsipo.nasa.gov” 

SB 

Life Sciences 

Kathy Bosovich 
Lenore Jackson 

K. Bosovich, (415) 604-5859 
bosco@nsipo.nasa.gov 

AMES :: "bosco@nsipo.nasa.gov" 

L. Jackson, (301) 286-7251 
NSSDCA::JACKSON 

1 iackson@nssdca.nasa.gov 

SN 

Microgravity Science and 
Applications 

TBD 

Christine Falsetti 

C. Falsetti, (415) 604-6935 
falsetti@ nsipo.nasa.gov 
AMES::"falsetti@nsipo .nasa.gov" 

SL 

Solar System 
Exploration 

Joanie Thompson 

J. Thompson, (415) 604^550 
joanie@ nsipo.nasa.gov 
AMES :: ”joanie@ nsipo.nasa.gov" 

SS 

Space Physics 

Maria Gallagher 

M. Gallagher, (415) 962-7753 

maria@nsipo.nasa.gov 

AMES::"maria@nsipo.nasa.gov" 


updated 3/20/91 




































Extract from a Sample Memorandum of Understanding 

If the customer represents the interests of a science program or project, they are encouraged to work 
with the Customer Service Manager, Christine Falsetti, to establish a Memorandum of Understand- 
ing (MOU). The MOU is a contract between NSI and an OSSA Science Project requesting network 
services. For many projects, this has proven the best way to uniformly state networking require- 
ments. The MOU is a valuable reference tool for the CSR as it states the roles and responsibliti.es 
of each party. 


MEMORANDUM OF UNDERSTANDING 

between 

PROJECT X 

and the 

NASA SCIENCE INTERNET 

for 

PROJECT X SCIENCE NETWORK COMMUNICATIONS 

September 31, 1990 

Approvals: 


name. Project Scientist, Christine M. Falsetti, Customer Service Manager 

PROJECT X NASA Science Internet 


name , Project Manager, Frederic N. Rounds, Project Manager 

PROJECT X 


name. Program Scientist, Anthony Villasenor, Program Manager 

PROJECT X NASA Science Internet 


name. Program Manager, Joseph Bredekamp, Chief 

PROJECT X Information Systems Branch 


name. Director, Ray J. Arnold, Director 

Astrophysics Division Communications and Information 

Systems Division 
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L PROLOGUE 


NASA Flight Projects as well as Discipline Data Centers have requirements to 
communicate with their investigators and system users. Many of these 
com m unications require electronic connections for digital data access and transport, 
for access to shared computational resources and software, and for electronic mail. 
Tide distributed nature of the investigators and users who have a wide variety of 
computer/software systems requires national as well as international connectivity 
operating in a heterogeneous environment. 

The NASA Science Internet Project (NSI) has been charged with integrating 
and implementing the Flight Project and Discipline Data Center network 
communications requirements within the NASA Office of Space Science and 
Applications (Code S) into a cost effective, efficient and reliable national 
communications network with international connectivity. A variety of computer 
systems and networking protocols are supported. The NSI-DECnet and the NSI- 
TCP/IP are both managed by the NSI in achieving its mission. The NSI works 
closely with the Code T Program Support Communications Program in providing 
these services. 

PROJECT X : this will be a brief description of what the project is about, its 
functions, goals or objectives. 

NASA OSSA Communications and Information Systems Division (Code SC) 
has programmatic responsibility and NASA Ames Research Center has project 
management responsibility for the NASA Science Internet. The NASA OSSA 
Astrophysics (Code SZ) has programmatic responsibility and appropriate NASA 
center has project management responsibility for PROJECT X. PROJECT X has both 
domestic and international science communications requirements that require the 
services of NSI. 

This Memorandum of Understanding (MOU) defines the PROJECT X 
Program science communications requirements on the NASA Science Internet and 
describes the roles and responsibilities of these two organizations in support of these 

requirements. 

II. INTRODUCTION 
A. PURPOSE 

This MOU documents the science computer networking requirements of 
PROJECT X and the corresponding services and equipment to be provided by the 
NASA Science Internet in support of these requirements. The MOU describes the 
roles and responsibilities of PROJECT X and NSI in the definition of requirements, 
design, procurement, implementation, use, operations, monitoring, maintaining, 
testing and evaluation of the NSI-provided networking services. This document sets 
the general agreements, constraints and interfaces between the two organizations. 
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Network Service Request Form 

The Customer Service Reps use the NSR to gather and document networking requirements. The 
information captured on the NSR must be complete and accurate as it is submitted to our Work 
Control Desk for entry into NSI’s master Requirements Database. 
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NASA SCIENCE INTERNET nsinsr# 
NETWORK SERVICE REQUEST 



From End-Point Site: 


Organization 


Facility 


Suborganization 


Building 


Point of Contao/NSI Site Coordinator 

(Point of Contact/NSI Site Coordinator} 

Email 

Email 

Commercial Phone FTS Phone 

[Commercial Phone ] [FTS Phone) 

Specific NASA Program/Project Refereu 

ice: 

Headquarters Code 

NASA Contract/Grant Number: 

IJPNNo.: 

[Expiration Date:! 

Proeram/Project Name: 

[Contracting Officer's Technical Representative] 



Description of Service (Cont'd): 

[Commercial Phone:] 
fFTS Phone:! 



2 of 2 
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Instructions For Completing the Network Service Request 


When a customer chooses to complete the NSR, we provide an NSR Packet which includes the 
Form Instructions, a blank form and samples of completed forms. 

Notice that the page layout of the NSR Form Instructions closely resembles the actual NSR form. 
This was not an accident. Keeping the customer in mind, it was seen as one of the best ways to 
guide the person through the form. Of course, your CSR is always available to answer questions 
or help complete the form. 
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NSR Form Instructions 

The NSR form is two sided. Side one has information your Customer Service Representative 
will need in order to submit your request for connectivity to NSI engineering. Side two has 
space for more detailed information regarding the nature of service you are requesting. 

Each field that appears on the NSR form is described in the subsequent table. 

Accompanying these instructions are samples of completed NSR forms. These examples are 
meant to serve as guidelines and are based on how a request might look when generated. Use 
the example that best fits your particular situation. 

Finally, if you still have difficulty, feel free to contact an NSI Customer Service 
Representative. 


Thanks so much for your cooperation. We look forward to working with you. 


NSI Customer Service Staff 


NSR Instructions page I 
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ne of 


Description of Services Requested: 


Requested Start Date: 



When vou want the service to start. 


When you want the service to stop, or the end of your 
scientific mission. 



From End User: This is the individual requesting the connectivit’ 


Last Name, First Name, Initial 


Organization: 


Suborganization 


E-Mail Address 


Host/Terminal Type 
rating System 


Existing External Network Addresses 


LAN connection 


Your last, first name and initial. Please include any titles 
and/or degrees you wish to be associated with. 


Name of the parent body with which you are affiliated. 


Your site’s physical location. 


Your division within your organization (sometimes this is 
the project name.) 


Your site's full address including suite or room number. 


Your electomc mail address. 


Type of computer you are currently using as the primary 
network resource. 


The numeric IP address or DecNet address. 


Is there a Local Area Network at your site? 
Are you connected to it? 


To Computing Resource (or another end user): Here is where you tell us what you need on the other 
end of the connection. A resource can be a network, a computer, or a person. 


Last Name, First Name, Initial 



The full name of the computing resource, type of resource 
needed, or individual with which you need connectivity. 


Parent organization with which you want connectivit 


Physical location of the site where you want connectivi 


rating System 


LAN Connection 


The full address of the remote resource (including suite or 
room number). 


Remote end user's electonic mail address. 


Name of the remote host computer where you need 
connectivity. 


The numeric IP address or DecNet address of the remote 
computer. 


Is there a Local Area Network at the remote site? 


Description of Service Requested: 

Your description should include the following: 

1. Briefly describe the nature of your scientific research and your project/piogram's current/future needs for 

network services. 

2. Type of service desired (what do you want the connection to accomplish for you? What will you expect to use 

the network for? To transfer research data? To send electronic mail? What else? 

3. What type of scientific data will be transmitted? How large are the files? 

4. How often (x per day) do you expect to use the network for the aforementioned purposes? 
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Field Reference: Side 2 of the NSR form 


This side describes the technical information that the NSI staff needs from you in order to work with remote 
locations and personnel in establishing your connectivity. 

End point to end point are the actual physical locations where the circuit will originate and terminate. NSI 
works closely with remote site technical personnel during all phases of establishing, and later, maintaining 
your network service. 


From End-Point Site 

Where your physical connection will originate 

Organization/Facility/Suborganization 

Same as side one 

Floor/Room 

The physical location of your host (server or networking 
resource) 

Point of Contact (NSI Site Coordinator) 

Your site's technical contact for NSI 

Email 

His/her email address 

Commercial /FTS 

His/her current phone number/s 


To End-Point Site 

Where your physical connection will terminate 1 

Organization/Facility /Suborganization 

Same as side one, but describing the remote site 

Floor/Room 

The physical location of the remote site; host (server or 
networking) resource 

Point of Contact (NSI Site Coordinator) 

The remote site's technical contact for NSI 

Email 

His/her email address 

Commercial /FTS 

His/her current phone number I 


Specific NASA Program/Project Reference: NASA/OSSA (Office of Space Science & Applications) 
has standard prerequisites for validating your request for connectivity. This part of the form ensures that you are 
eligible for connectivity under NASA/OSSA regulations. 


Note: In order to receive service from NSI, you must establish that you are part of a valid NASA/OSSA (Office 
of Space Science Applications) funded program or project All requests for connectivity go to NASA headquarters 
for validation. If you are not sure about the validity of your project status, please contact your site CQTR 
(Contracting Officers Technical Representative) for more information. If you are unsure of how to contact your 
CQTR, please contact an NSI CSR . 


Headquarters Code 

The OSSA code with which you are affiliated 

UPN Number 

The NASA code identifier 

Program/Project Name 

The name of the NASA project with which you are 
affiliated 

NASA Contract/Grant Number 

The numerical contract or grant number that proves you are 
funded by NASA. Please make sure that you include the 
expiration date. 

Contracting Officer's Technical Representative 

The NASA official at your site who oversees and directs 
funding for your NASA contract or grant This is the person 
to contact regarding questions you may have about 
validation. 

Commercial Phone /FTS Phone 

The COTR’s current phone number 

Description of Service (Con't'd) 

More space to finish your description from side one 


NSR Instructions page 3 
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NASA. SCIENCE INTERNET NSINSR * 

NETWORK SERVICE REQUEST 


*?£> M o 


RETURN TO: 

NASA SCIENCE INTERNET PROJECT OFFICE 

Mail Stop 233-8 

NASA ..Ames Research Center 
Moffett Field, CA 94035-1000 
Commercial: (415) 604-5359 FTS: 464-5359 
FAX: (415) .604-6999 FTS: 464-6999 


Descriptions of Services Requested: 

Requested Start Date: 3 ^ 0 

From End User: T 




Estimated Stop Date: _i — JL 

To Computing Resource (or anotker End User): 


Oigsuaoonl 


(Faoluyj 


ISubosganzanoni 


City - , 

?>G 4- : 


■- 66'4'(5 


Description of 


Hi a-rU& 

V' 

YiaHtr-emA^ 

c 


NSIFom i (May 90) 
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ORIGINAL PAGE m 
OF POOR QUALITY 







Sample Notification of Receipt 


Completed NSR in hand, the customer’s request for networking services is often acknowledged in 
a letter such as this. But sometimes, the CSR breaks down and employs the "other" technology (ie 
telephone). On to the validation step! 


310 



NASA Science Internet Project Office 
NASA/Ames Research Center 
M/S 233-8 

Moffett Field, CA 94035-1000 


December 21, 1990 

Dr. James G. Mantovani 
Florida Institute of Technology 
Dept, of Physics & Space Sciences 
150 W. University Blvd. 

Melbourne, FL 32901-6988 


Dear Dr. Mantovani, 

I have received your request for a "SPAN" network connection to support your JGVE-sponsored 
research. It has been documented as NSR 21338 and you can get status by contacting me. 

As your request is explicitly for a "SPAN" connection, I thought that the following explanation 
would be helpful: 

The NASA Science Internet Project is currently consolidating the "SPAN" and "NASA Science 
Network" circuits into a network called the NASA Science Internet (NSI). Architecturally speak- 
ing "SPAN" is being redesigned, but the DECNET functionality will still exist. This is because the 
NASA Science Internet supports both DECNET and TCP/IP networking services over the same 
circuits. 

I am delighted to tell you that there already exists an NSI Interoperability Gateway which supports 
file transfer, remote logins from your Internet-resident VAXes to VAXes on the NSI "DECNET" 
and electronic mail. As it is possible that the Interoperability Gateway might satisfy your "DEC- 
NET" networking needs I am enclosing the documentation and ask that you try it out. 

However, I will still want to discuss networking issues with you over the phone. You can expect 
to hear from me in early January 1991 when I return from vacation. 

Sincerely, 

Joanie Thompson 

415/604-4550 

joanie@nsipo.nasa.gov 


cc: CFalsetti 
NSR21338 
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Sample Validation Packages 


Since every request for network connectivity must be validated, the CSRs have developed a stan- 
dard "Validation Package" for submission to the appropriate Validation Contact at NASA Head- 
quarters. The "Package" consists of a cover letter and Validation Sheet which is signed and re- 
turned to our office. The Customer Service support staff maintains a log to track the progress of 
the "Package" while at Hq. 


National Aeronautics and Space 
Administration 

Ames Research Center 
Moffett Field, California 94035-1000 


r\JASA 


Reply to Attn of: ED:233-8 


October 29, 1990 


Mr. Greg Hunolt 

National Aeronautics and Space Administration 
Code SE 

Washington, D.C. 20546-0001 


Dear Mr. Hunolt: 

Please review the attached Code SE Validation Sheets for NASA Science Internet service. If we are to 
implement this service, we require your validation before proceeding. If you are unable to validate this 
request, please provide a brief explanation on the Validation Sheet. In either case, your signature is 
required. 

The Customer Service Representative for Code SE network service requests is Kathy Bcsovich. She 
will be happy to provide you with any additional information or status on any Code SE network request 
Kathy can be reached at FTS 464-5859, (415) 604-5859 or by NASAMAEL: kjbosovich. 

Return signed validation sheets to your Customer Service Representative, Kathy Bosovich at: 

NASA Ames Research Center 
NASA Science Internet Office 
ms: 233-8 

Moffett Field, CA 94035-1000 
FAX (415)604-6999, FTS 464-6999. 



'Christine M. Falsetti 
Customer Service Manager 
NASA Science Internet Office 


cc: DPuku 
FRounds 
KBosovich 
MGoodman 
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NASA HQ VALIDATION SHEET 
from the 

NASA Science Internet Office 
October 29, 1990 


The following narrative describes a request for networking services. We ask that you review it and indicate whether 
the requirement is valid or not valid. If not valid, please provide a brief explanation. If you require more 
information about this request, contact the Customer Service Representative (CSR) for Code SE. 

Mr. Michael Goodman at Marshall Space Flight Center has requested general Internet connectivity for the following 
locations in support of the WETnet Project. WETnet needs capability to transfer files from mainframe to mainframe . 
McIDAS without using McIDAS communication protocols, and interactive file transfer between mainframe 

McIDAS and PC -McIDAS. 

Listed below are the location that are requested for WETnet connectivity: 

Eric Barrett, Remote Sensing Unit, University of Bristol, England NSR 21122 
Francis Bretherton, Space Science & Engring Ctr, Univ of WI, NSR 21123 
Robert Brown, Dept of Atmospheric Sciences, Univ of WA, NSR 21124 
Robert Chase, CO Ctr for Astrodynamics Res Univ of CO, NSR 21127 
William Emery, CO Ctr for Astrodynamic Res, Univ of CO, NSR 21131 
Robert Craws, Dept of Geography, Pennsylvania State Univ, NSR 21 129 
lory Felde, Geophysics Laboratory (AFSC), Hanscom AFB, NSR 21132 
Catherine Gautier, Univ of CA-San Diego, Scripps Insititute, NSR 21133 
Barry Rock, Univ of New Hampshire, NSR 21137 
William Olion, Univ of Wisconsin-Madison, NSR 21136 
John Janowiak, NOAA/NWS/NMC-Climaie Analysis Ctr, W.D.C., NSR 21134 
Rod Scofield, NOAA/NESDIS, Camp Springs, MD, NSR 21139 


Please indicate if this request is: (check one) 

valid requirement for Code SE. 

not a valid requirement for Code SE. (Please provide brief explanation 

below.) 


comments: 


Signed: 



Date: 



<a , mo 


Please return to: 

Kathy Bosovicfa 

NASA Ames Research Center 

NSIO 

ms: 233-8 

Moffett Field, CA 94035-1000 
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National Aeronautics and Space 
Administration 


Ames Research Center 
Moffett Reid, California 94035-1000 


NASA 


Rap* » Am of: ED:233-8 February 14, 1991 


Dr. James Willett 
Code SS 

National Aeronautics and Space Administration 
Washington, D.C 20546-3191 


Dear Dr. Willett: 

Please review the attached Code SS Validation Sheets for NASA Science Internet service. If we arc to 
implement this service, we require your validation before proceeding. If you are unable to validate this 
request, please provide a brief explanation on the Validation Sheet. In either case, your signature is 
required. 

The rnctnmrT Service Representative for Code SS network service requests is Maria Gallagher. She 
will be happy to provide you with any additional information or status on any Code SS network request. 
Maria can be reached at FTS 464-3601, (415) 604-3601 or by NASAMAEL: mlgallagher. 

Return signal validation sheets to your Customer Service Representative, Maria Gallagher at: 

mail stop 233-8 
NASA Ames Research Center 
NASA Science Internet Office 
Moffett Field, CA 94035-1000 

FAX (415)604-0063, FTS 464-0063. 


Thlqk you for your assistance. 



Christine M. Falsetti 


Customer Service Manager 
NASA Science Internet Office 



cc: MGallagher 
DPuku. 
FRounds 
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NASA HQ VALIDATION SHEET 
from the 

NASA Science Internet Office 
February 14, 1991 


The following narrative describes a request for networking services. We ask that you review it and indicate 
whether the requirement is valid or not valid. If not valid, please provide a brief explanation. If you require 
more information about this request, contact the Customer Service Representative (CSR) for Code SS, 

Maria Gallagher. 

Gordon Lentz of the University of Chicago has requested an upgrade in the existing 9.6 DECnet 
circuit from the University of Chicago to MSFC, in anticipation of a substantial increase in use of 
the network to support various experiments on both the CRRES and Ulysses spacecraft (NSR 

#21299) 

The PI at the University of Chicago is Dr. J. Simpson who is working with various Co- 
Investigators in both the U.S. (primarily at JPL and AFGL) and Europe. (NSR #21300) 

Hie connectivity will be used for quick-look data access from the ionboard experiments on both 
crafts, as well as increased data exchange and transfer among the experimenters. 


Please indicate if this request is: (check one) 



a valid requirement for Code SS. 


_ not a valid requirement for Code SS. (Please provide 
brief explanation below.) 


comments: 


Signed: . 




Dir. James Willett, NASA HQ: Code SS 


Date: 


7 - 




note: For tracking purposes, NSI has assigned these requests as #21299 and #21300. Your Customer 
Service Representative can provide more information and/or status on these NSRs. 


Please return to: 


Maria Gallagher 
ms: 233-8 

NASA Science Internet Office 
NASA Ames Research Center 
Moffett Held, CA 94035-1000 

(415) 604-3601 
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Headquarters Validation Contacts 


The following chart shows who the CSR applies to for Validation of requirements. Validation is 
a necessary and crucial step in the NSR Process since NSI Engineering is unable to perform cost 
analyses, design network solutions or order circuits without it. 


CHRISTINE FALSETTI 
CUSTOMER SERVICE MANAGER 


CODE 

DISCIPLINE 

CUSTOMER 

SERVICE 

REPRESENTATIVE 

HQ OFFICIAL 
VALIDATOR 

DESIGNATED 

VALIDATOR 

S 

Office of Space Science and 
Applications 

Joanie Thompson-JOVE 

Dr. Joseph Alexander (Code 
S) 

Robert C. Rhome (Code R) 


SZ 

Astrophysics 

Joanie Thompson 

Dr. Frank Giovane 

Dr. Guenter Riegler 

SC 

Communications 

Maria Gallagher 

Dr. Anthony Villasenor 


SE 

Earth Science and 
Applications 

Kathy Bosovich and Lenore 
Jackson 

(Dr.) Greg Hunolt 


SM 

Flight Systems Division 

TBD/Christine Falsetti 

Dr. Phillip J. Cressy Jr. 


SB 

Life Sciences 

Kathy Bosovich 

Dr. Richard (Dick) Keefe 

D. Duncan Atchison 
(Lockheed) 

SN 

Microgravity Science and 
Applications 

TBD/Christine Falsetti 

(Dr.) Mary Kicza 


SL 

Solar System Exploration 

Joanie Thompson 

Dr. Guenter Strobel 


SS 

Space Physics 

Maria Gallagher 

Dr. James Willett 

(Dr.) Eldon Whipple 



Sample Rejection Letter 


Not very often, the Headquarters Validation Contact flags a requirement as invalid and the CSR 
drafts a letter like the following. 
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July 31, 1990 



Mr. Alan Strong 
Project Coordinator, CEORS 
Department of the Navy 
United States Military Academy 
Annapolis, MD 21402 

Dear Mr. Strong, 

We regret to inform you that your request for connectivity to 
the NASA Science Internet has been denied. 

All of our requirements must go through the NASA 
headquarters validation process in order to be approved for funding. 
When your request was submitted to NASA headquarters for 
validation, neither Dr. George Ludwig (Earth Sciences Discipline 
validator) nor Dr. Marion Lewis were able to associate your request 
with a valid NASA OSSA program or project. 

Currently, we consider this request closed. Further supporting 
documentation providing evidence of a NASA/OSSA grant or contract 
for your site is needed if you wish to pursue this matter further. If 
you have any questions, please feel free to contact me at the number 
below. Thank you for your patience in this matter. 


Sincerely, 
Lenore Jackson 


NSI Customer Service Representative 
Code SE 

( 301 ) 286-7251 

NSSDCA: JACKSON 

jackson@nssdca.gsfc.nasa.gov 
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Interface with Engineering 


Once validated, the CSR introduces the requirement to the NSI Engineering staff. The Engineering 
Manager assigns one of his staff to seek costing estimates and perform design analyses and makes 
recommendations on implementation. The Engineering Manager makes the final decision on im- 
plementation. 

The CSR staff maintains records and tracks the progress of requirements through this phase of the 
process too. 
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WHAT : Agenda for the Requirements Engineering Meeting 

WHEN: Thurs, March 7, 1991 2:30-3:30 

WHERE: Room 247 

WHO: Engineering staff and Customer Service Reps 

NEW REQUIREMENTS 


NSR 21299 

PROJECT : 
CSR : 

Request for upgrade to existing NSI-DECnet services between 

Univ of Chicago and MSFC, GSFC 

CRRES 

Maria 

NSR 21300 

PROJECT : 
CSR: 

Request for upgrade to existing NSI-DECnet services between 

Univ of Chicago and JPL 

Ulysses 

Maria 

NSR 21366 

PROJECT: 

CSR: 

Reqmt for Email, remote logon, file transfer between University of 

Puerto Rico and MSFC 

JOVE 

Joanie 


ACTIVE REQUIREMENTS open for discussion 


NSR 21027 

PROJECT : 

CSR: 

History 

Request to upgrade existing 9.6 NSI-DECnet to 56Kbps dual-protocol 
between GSFC and Yale University. 

Code SZ Astrophysical Theory Program 
Joanie 

02/28/91: 

03/07/91: 

Eng requested copies of the users proposal to NSI. 


NSR 21345 

PROJECT : 

CSR: 

History 

Onizuka AFB, Sunnyvale, CA to ARC 

NSI/DECnet services requested to support researcher. 

CRRES 

Maria 

01/31/91: 

02/21/91: 

02/28/91: 

03/07/91: 

Milo M. recommends NSI use PacBell for this reqmt. Concurrence 
by Bill J. SR to B. Yeager required. NSI to provide DSU & maint. 
Mark to prepare and submit SR. 

Thom delegated job of preparing SR. ARC POC is Jeff Burgan. 

NSR 21352 
PROJECT : 
CSR: 
History 

Internet connectivity from Crystal City, DC to NASA HQ 
Scientific and Technical Info Division Code NT 
Kathy 

01/31/91: 

Eng will talk to Jeff concerning this issue. Ckt provider 
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Customer Notification of Completion/Confirmation 


In reality, the CSR is alerted by the NSI Network Manager when the service is in place and oper- 
ational. A phone call to the customer is usually made before the Notification of Completion/Con- 
firmation is produced. 

From this point forward, the CSRs’ role is largely complete. But there are two other NSI groups 
who are providing services to the network user; NSI Operations Center (NOC) and NSI User Sup- 
port Office. 

With the help of sophisticated Network Monitoring techniques. The NOC Staff are able to act upon 
network problems well before the users notice and report the problem. Network monitoring is on- 
going 24 hours a day, 7 days a week. 

The NSI User Support Office staffs a user help desk which is the first stop for all user questions/ 
problems. The help desk is available 12 hours a day, 5 days a week with off-shift support from the 
NOC. The office also maintains an on-line Network Information Center (NIC) which is available 
through the network. 



NASA Science Internet Project Office 
NASA/ Ames Research Center 
M/S 233-8 

Moffett Field, CA 94035-1000 


May 16, 1990 


Dr. Joseph Veverka 
Cornell University 

Center for Radiophysics & Space Research 
422 Space Sciences Bldg. 

Ithaca, NY' 14853 


Dear Dr. Veverka, 

Your request for an upgrade to the existing network service between Cornell University and JPL 
to facilitate your work as a member of Galileo’s Solid-State Imaging team has been implemented 
and is now fully operational. 

NSI Engineering has worked with Mr. Joel Plutchak for your site to verify that the circuit is per- 
forming reliably. NSI Operations will monitor the circuit 7 days a week, 24 hours a day. Should 
you experience problems with this new service, your first course of action should be to contact your 
local networking expert who would then contact NSI Operations staff should it be necessary. 


Sincerely, 


Joanie Thompson 
NSI Customer Services 
415/604-4550 


cc: Ted Clarke/JPL 
Mark L eon/ ARC 
Christine Falsetti/ARC 
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What the CSRs would like their customers to understand is that the CSR is the focal point for get- 
ting the requirements into and through the NSR Process. There are a number of internal and ex- 
ternal groups which the CSR interfaces with to complete a service request. The following article 
indicates the groups while describing the process. 
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Requirements Management in the NASA Science Internet 
by Deborah D. Puku 

In October 1990, the NASA Science Internet (NSI) Project established the Customer Service 
group to manage collection of OSSA program and project science data communications 
requirements. Currently, the Customer Service responsibilities include communications 
requirements management, program and project interface, publication distribution, and other value- 

added services for NSI. 

The Customer Service group is managed by Christine Falsetti at NASA Ames Research 
Center, who reports directly to Fred Rounds, the NSI Project Manager. Currently, group 
members are located at Ames Research Center and Goddard Space Flight Center. Customer 
Service representatives (CSRs) are assigned the requirements management responsibilities by 

OSSA discipline, as follows: 


I CODE 

DISCIPLINE 

CUSTOMER 

SERVICE 

REPRESENTATIVE 

SZ 

Astrophysics 

Joanie Thompson 

SC 

Communications 

Maria Gallagher 

SE 

Earth Science and 
Applications 

Kathy Bosovich and 
Lenore Jackson 

SM 

Flight Systems 
Division 

TBD/Christine Falsetti 

SB 

Life Sciences 

Kathy Bosovich and 
Lenore Jackson 

SM 

Microgravity Science 
and Applications 

TBD/Christine Falsetti 

SL 

Solar System 
Exploration 

Joanie Thompson 

SS 

Space Physics 

Maria Gallagher 


PHONE NUMBER AND 
EMAIL ACCESS 

K. Bosovich, (415) 604-5859 
bosco@nsipo.nasa.gov 

M. Gallagher, (415) 604-6362 
maria@nsipo.nasa.gov 

C. Falsetti, (415) 604-6935 
falsetti@nsipo.nasa.gov 

L. Jackson, (301) 286-7251 
jackson@nssdca.gsfc.nasa.gov 

J. Thompson, (415) 604-4550 
joanie@nsipo.nasa.gov 


For NSI service, program and project managers are encouraged to work with the NSI 
Customer Service Manager to establish a Memorandum of Understanding. (Individual requestors 
seeking NSI services should contact their discipline CSR: see chart.) A Memorandum of 
Understanding (MOU) is a contract between NSI and the program or project requesting network 
services. It describes the roles and responsibilities of each party, and details the requirements for 
wide area network connections. An MOU also offers several advantages: program requirements are 
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uniformly documented, MOU customers are given project priority, requirements are documented in 
the NSI budget cycles, and the requests for service are potentially expedited through the validation 
process. 

As an MOU is being negotiated, a CSR is assigned and a Science Networking 
Representative (SNR) from the OSSA program or project is identified. Requests for network 
connections are documented on a Network Service Request (NSR) form by the Science 
Networking Representative with the help of the Customer Service Representative. The 
requirements are tracked through the NSR process as outlined in brief here: 

I. Requirements Gathering— 

Information needed includes site addresses, host/terminal type, any existing network 
connection information, and a comprehensive description of service requested. Also necessary are 
names of the associated OSSA program or project, NASA Headquarters code, grant numbers, and 
names needed for Headquarter validation and approval. 


II. Headquarters Validation- 

Note: This step can be waived with an approved MOU. When the NSR is complete, a 
description of service is forwarded to the designated validator of the appropriate discipline at 
NASA Headquarters (i.e.. Life Sciences, Astrophysics, etc.). The discipline involved then 
reviews the request and decides whether the service is necessary and relevant in support of the 
identified OSSA program/project. This process can take anywhere from a week to months, 
depending on the schedules of OSSA discipline representatives. 


III. Engineering Review — 

Once the NSR is validated, NSI Engineering performs design analyses. Decisions are 
based on a number of factors including existing network connections or proximity, and use of 
shared bandwidth. The goal is to maximize bandwidth efficiency while delivering the desired level 
of performance to the user. 


IV. Administration Review— 

The Engineering plans, when complete, are then given to Administration for a budget 
review. If the request is submitted early enough, cost can be forecasted into NSI's budget for the 
appropriate fiscal year. Many NSRs are entered years in advance to ensure they will be funded by 
NSI. 

V. Implementation— 

The NSI Site Installation and Engineering Teams work with the Program Support 
Communications Network and other circuit providers to implement design plans and ensure that 
the connection is functional and running. 


VI. Operations— 

All network connections are monitored 24 hours a day, seven days a week. NSI 
Operations has a hotline number for immediate service, (415) 604-3655. They monitor the wide 
area network, diagnose and verify problems, coordinate resolutions, and track and document 
findings. 

Through all phases of the NSR process, the user has one designated CSR. The CSR will 
keep the users updated and notified on any status chang es. 

An important complimentary function to the requirements management process is NSI 
support of major OSSA conferences by providing network connections to attendees. This allows 
members of the science community access their home institutions for electronic mail, remote login, 
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and file transfers. It also allows attendees to meet their CSRs, pick up documentation, and discuss 

the requirements process. 

If you would like to benefit from any of the services provided by the NSI Customer 
Service group, please contact your appropriate Customer Service Representative listed in the chart 

above. 
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NASA Science Internet (NS1) 
Overview of the NSI User Support Office 

NSI USO 


Lenore A. Jackson 

Advanced Data Flow Technology Office 
STX/Code 930.4 
Goddard Space Flight Center 


Presentation to 

NASA Science Internet User Working Group 

February 12, 1991 




TS 
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Overview of the NSI/USO 



• Hot Line for User Questions 


• NSI Database Updates 

• Documentation 


• Toolkit Distribution and other On-Line Services 



Overview of the NSI/USO 


Hotline for NSI Questions 


Phone calls, Electronic Mail Messages, FAX, and Walk-ins 


- Automated log of user Network Problems/Resolutions 


- NSI Network Information 

• E-Mail between networks (e.g., DECnet, BITNET, TCP, 
DECnet 


lift iM 




SI/DECnet da 


Site contact information 


Node contact informatioi 
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Overview of the NSI/USO 


• Available Documentation 

- NSI Cookbook (formerly SPAN Cookbook) 

- Management of NSl/DECnet (formerly SPAN) 

- Security Policies and Procedures 

- The Yellow Pages 

- Using - East - Gateway- E-Mail Syntax 


- Various NSI Publications 
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Overview of the NSI/USO 


N 




• On-Line Services via NSI NIC 
- Documentation 

• Cookbook 

• E-Mail Syntax 

• DEGnet Database Distribution 

• NPSS Access Via Marshall Network Control 


Pass-Thru Account 




Overview of the NSI/USO 


• N Si Database Update and Distribution (DECnet/TCP) 

- Establish a working relationship with routing center liasons 

- Receive node additions and deletions from approved sources 
(DECnet) 

- Update internal files for office purposes 

- Run Genlist.com produces area US files 

- Run buildeCom pmduces-US DECnet database 

• Checks for duplicate nodenumber and/or nodename 

• Automatically deletes all extraneous information 

- Correct any discrepancy and re-run build com 

- The new DECnet SPAN - DB. is automatically moved to the 

DECnet Default directory where it is accessable to all DECnet 
Routing Center liasons and tail sites. 


WHO YOU GONNA CALL? 




NASA Science Internet User Support Office 

(NSI USO) Code 930.4 
Advanced Data Flow Technology Office 
Goddard Space Flight Center 
Greenbelt, MD 20771 

301-286-7251 FTS 888-7251 

(alt. 301-286-9514/FTS 888-9514) 

(FAX 301-286-5152) 


DFTNIC::NSIHELP (6148::NSIHELP) 

nsihelp@dftnic.gsfc.nasa.gov (nsihelp@128. 183. 10.3) 

(C:USA,A:TELEMAIL,P:INTERNET,ID:"<nsihelp(a)dftnic.gsfc.nasa.gov> ) 


NSIHELP@DFTBIT 


BL 7,/B/Hl 



Brian Lev 

Advanced Data Flow Technology Office 
STX/Code 930.4 
Goddard Space Flight Center 


Prc 
:e I 
Fe 
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T he NSINIC On-Line System 


L Background 

A. A Little NS1 History 

B : , The ABFTO's Other On-Line Servers 

II. NSINIC On-Line 

A. The Current System 

B. How It Works 

C NSINIC: The Next Generation 

III. Summary 


8L 2/8/11 
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The NSINIC On-Line System 


General Background: 

NASA became involved with dedicated wide-area networking with 
the establishment of the DECnet-based Space Physics Analysis 
Network (SPAN) in 1981 and the TCP/IP-based NASA Science 
Network (NSN) in 1987 . 

After a series of NASA Network Management Retreats in late 1990, 
SPAN and the NSN were joined into a unified NASA Science Internet 
(NSI). 

With establishment of the unified NSI, the Goddard Space Flight 
Center was tasked with setting up a Network Information Center 
(NIC), which was to include an on-line user help system. 


The NIC staff made the decision to temporarily host the NSINIC 
system on already existing on-line systems in use for SPAN and the 


GSFC LAN. 


PL 2/B/m 



The NSTNIC On-Line System 


Network Servers Provided bv Goddard's ADFTO 

A . Services Hosted on DFIMC.gsfc.nasa.gov (VAX 8250) 

1 . NSI Network Information Center On-Line System (NSINIC) - new service. 

2. Network Information On-Line Aid System (NICOLAS) -- approx. 102 user logins/day, current total over 77000. 
Listed in the Internet Resources Guide by invitation. 

3. Anonymous FTP File Server - Approximately 1.5 MB disk space allocated to 236 VMS and Macintosh files; 
currently averages over 9 accesses per day. 

B. Services Hosted on DFTSHV.gsfc.nasa.gov (Sun 3/260) 

1. USENET News Server - Over 140 MB disk space allocated to more than 800 newsgroups, supporting 76 client 
systems; sample monitoring has shown up to 25 simultaneous users 

2. Anonymous FTP File Server - 48 MB allocated to over 200 UNIX, VMS and Macintosh files; averages over 20 
accesses per day. 

C . Services Hosted on DFTSUN4.gsfc.nasa.gov (Sun 4/260) 

1. White Pages Server - Entire GSFC telephone book available, as well as listings for all other White Pages 
project participants (over 100 sites); accessible with login "fred". 

D Services Hosted on NSSDCAgsfc.nasa.gov (VAX 8650) 

1. SPAN Network Information Center On-Line System (SPAN_NIC) - First of NASA's major on-line network 
servers; includes NSI-DECnet (formerly SPAN) node database queries, "how to" files, and network 
documentation. Will be folded into next release of NSINIC system. 
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The NSINIC On-Line System 


Other On-Line Services Provided bv the AD FTP 

A . Services Hosted on DFTNIC (VAX 8250) 

1. BITNET Access Server -- Encapsulates BITNET (RSCS) packets in DECnet; currently supporting ROSAT and 
Crustal Dynamics projects at Goddard. 

2. X.25 Access Server -- Encapsulates X.25-related packets in DECnet; currently supporting ROSAT and several 
Code 500 projects at Goddard. 

3. DNS/DFS Server - Supporting approx. 25 nodes in the CAC and CSDR clusters at Goddard. 

B. Services Hosted on DFTSRV (Sun 3/260) 

1. TCP/IP Domain Name Server - Recorded over 12 accesses/minute during work hours. 


BL Z/B/Sl 
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T he NSINIC On-Line System 




mfFrq? 


The Current System : 

Hosted on the DFTNIC VAX 8250, which is part of both NSI-DECnet 
and NSI-TCP/IP, with additional links to BITNET. 

Basically a "skeleton" system that allows easy access to SPAN_NIC 
and NICOLAS, provides an on-line problem reporting utility, provides 
information about the NSI and help contacts for individual NASA and 

ESA sites. 

System is hardware independent; NSINIC looks and acts the same on 

many different Muds of terminals. 

User-friendly menu interface. 


ULI/B/'M 
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The NSINIC On-Line System 


NSINIC TOP MENU 


[ 

11 

HOW TO USE THIS SYSTEM 


[ 

2 ] 

Info About the NSI and Other 

Nets 

[ 

3 ] 

NSI Personnel for Additional 

Help 

[ 

4 ] 

HELP FILES AND INFO 


[ 

51 

Connect to SPAN NIC 


[ 

6 ] 

Connect to NICOLAS 


[ 

7 ] 

Report A Problem 




== HELP FILES AND INFO == 


[ 1] E-Mail Syntax Matrix 
(2) The EAST Interoperability 
[ 3] How to Transfer Files 
[ 4 ] ... 


Gateway 



The EAST Interoperability Gateway 


The NASA Science Internet Project Office 
(NSIPO) has funded an Interoperability 
Gateway to facilitate the exchange of 
E-Mail, file transfer and remote logon 
capability between TCP/IP-based networks 
and DECNet-based networks. 

The Interoperability Gateway at Goddard 
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T he NSI NIC On-Line System 


The Welcome Banner ; 

Once logged in, users are presented with the NSINIC "Welcome Banner", 
where system messages will be posted as needed. 


DFTNIC.GSFC.NASA.GOU / 128.183.10.3 / DECnet node 6148 


We I come to . . . 

<<<<<<<<<<<<<<<<<<<<I !>>>>>>>>>>>>>>>>>>>> 

<<<<<<<<<I NSINIC ON-L I NE | >>>>>>>>> > 
<<<<<<<<<<<<<<<<<<<<||>>>>>>>>>>>>>>>>>>>> 

The NS I Users' On-Line Friend 

THIS SYSTEM IS FOR NASA EMPLOYEES, CONTRACTORS AND AFFILIATED RESEARCHERS 

| WELCOME TO THE NSINIC ON-LINE USER HELP SYSTEM! THIS IS A NEU SERUICE, I 
| AND SOME PARTS ARE STILL UNDER CONSTRUCTION, SO PLEASE BEAR WITH US. IF | 

| YOU ENCOUNTER ANY DIFFICULTIES, CALL THE NS I USO AT 301-286-7251 OR SEND | 

| EMAIL TO NSINIC: : NS I HELP OR NSIHELP&NSINIC. I 

+ + 

Press RETURN or ENTER to continue: 1 


NOTE: Unlike NICOLAS, there are no "passthrus" to other systems available at this point. 


BLZ/B/ll 
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This menu is the central point from which all NSINIC features can be 
accessed; it can be reached from any other menu by entering 'T" at the 
prompt. 



SL i/B/Hl 




The NSINIC On-Line System 
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Menu-Specific Help ; 

Each menu has its own help file, detailing what the various choices are 
and listing any system commands available from that menu. These help 
files can be accessed from any menu by typing "H" at the prompt. 


NSINIC TOP NENU HELP ##*##*#»################*«#*##*####*#»#»«***### PAGE 1/2 

Vou are currently in the Top Menu. This is "home base" for the entire system; 
from here, you can move to any of the other menus or utilities by entering the 
appropriate choice number at the " >“ prompt. 

WHAT THE OPTIONS ARE 


[ 1] INFO ABOUT THE NS I AND OTHER NETS: This brings up a menu from where you 
can access info on the NS I (including instructions on acquiring NS I 
connectivity) as well as information about other wide-area networks. 

I 21 NS I PERSONNEL FOR ADDITIONAL HELP: This brings up a menu that lets you 
look up names and numbers of NSI contacts at individual NASA centers. 

[ 31 HELP FILES AND INFO: This brings up a menu with instructions for sending 
Email, files xfers, using NSI interoperabi I i ty gateway(s), and more. 

[ 4 ] CONNECT TO SPAN-NIC: This logs you directly into the SPAN-NIC on-line help 
system, which carries ♦extensive* information about NSI-DECnet. 

[ 51 CONNECT TO NICOLAS: This logs you directly into Goddard’s NIC On-Line Aid 
System, which included several very handy automated utilities. 

[ 61 REPORT A PROBLEM: This automated utility allows you to send a flagged 
message to the NSINIC staff alerting us to any user problems. 



NOTE: This example shows the first page of the help file for the Top Menu. 
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The NSINIC On-Line System 


Menu-Specific Help (cont'd) : 


This is a sample of the 2nd page of a menu help file, detailing the system 
commands available from that menu. 


NSINIC TOP MENU HELP **n»***»**uu**#***uu*»*u**ttnuuu»*u»»***tt##uuttu* PftGE 2/2 

"TOP MENU- 

OTHER COMMANDS VOU CRN ISSUE 

[ E 1 X I T : log out of the system (return to your home system) 

[H1ELP: displays this help file 

[P1REUI0US: go directly to the previous menu 

[Q1UIT: log out of the system (return to your home system) 

[R1EFRESH: re-paints the menu display 
IT10P: go directly to the NSINIC Top Menu 

[U1ERSI0N: information on the current version of the NSINIC drivers 


Document IDO? 


NOTE: This example shows the second page of the help file for the Top Menu. 


»L2/B/S1 
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The NSINIC On-Line System 


U> 

00 


NSINIC: Ths Next Gcr.sr 


u 1 1 v/ 11 


Current plans for the first series of system enhancements concentrate 
on more information content: more "how to" and "what is" type files, 
increased coverage of companion wide-area nets, etc. 

Other planned enhancements call for inclusion of the SPAN data base 
and other functions and files from SPAN_NIC, as well as access to 
TCP/IP information (and possibly other automated utilities). 

In the more distant future... an X-based system? Expert system user 
queries? 

The bottom line: NSINIC enhancement and evolution will be driven 
by user requirements . 


BLZ/i/ll 
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The NSINIC On-Line System 


In Summary... 

This is only version 1.0 of a system we expect to grow and evolve 
over time in reaction to user requests and requirements. 

SPAN_NIC will be folded into NSINIC over a period of months, even- 
tually going off-line once the newer NSINIC can furnish an equal 
level of support to NSI-DECnet users. 

NSINIC is only one aspect of the new NASA Science Internet User 
Support Office (NSI USO) recently established at Goddard; for more 
information, send electronic mail to NSXNIC::NSIHELP (DECnet) or 
nsihelp@nsinic (TCP/IP). 


BL 2/0/ 'll 


350 




T “1 “ik T £""^4 ‘W’Wk TT ‘W ® a 

he NS1N1C On-Line System 


How to Get There : 

To access the NSIWIC on-line system from a DECnet node: 

$ SET HOST BFTNIC <CR> (If your system does not know DFTNIC, use DECnet 

address 6148 instead.) 

Username: NSINIC <cr> 


To access the NSINIC on-line system from a TCP/IP node: 

$ TELNET DFTNIC <CR> (If your system does not know DFTNIC, use TCP/IP 

address 128.183.10.3 instead.) 

Username: NSINIC <cr> 
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WHO YOU GONNA CALL? 


NASA Science Internet User Support Office 

(NSI USO) Code 930.4 
Advanced Data Flow Technology Office 

Goddard Space Flight Center 
Greenbelt^ MB 20771 

301-286-7251 FTS 888-7251 

(alt. 301-286-9514/FTS 888-9514) 

(FAX 301-286-5152) 

DFTNIC::NSIHELP (6148::NSIHELP) 

nsihe lp@dftnic .gsfc.nasa.gov (nsi .help® 128.183.10.3 

(C:USA,A:TELEMAIL,P:INTERNETJD:Vnsihelp(a)dftnic. gsfc.nasa.gov>") 

NSIHELP@DFTBIT 



The NSI User Support Office (NSIUSO) Presents... 

THE NASA SCSEMCE INTERNET NETWORK INFORMATION CENTER 

(NSINfC) ON-LINE SYSTEM 

NSiNIC is a menu-driven help facility designed to aid both novice and experienced users of the NASA Science internet. 
NSINiC includes user guides for general and inter-operating networking functions (e.g., remote logins and file transfers); 
listings of who to call for help at individual NASA centers; and genera! information about the NSI. Automated utilities within 
NSINIC provide transparent access to on-line help and other systems. Users are encouraged to access the NSINIC on-line 
system and leave comments. 


Accessing NSINIC: 


...from a TCP/IP System: T ELNET to DFTNIC.gsfc.nasa.gov (128.183.10.3); username is NSINIC. 
...from a DECnet System: SET HOST to DFTNIC (DECnet address is 6148); username is NSINIC. 


...via Dial-Up Links: Dial the appropriate access number as shown in the following table (all are area code 301), 
then follow the instructions listed below: 


300-2400 

300-2400 

9600 

9600 


Parity 

ODD/NONE 

EVEN 

NONE 

EVEN 


BiLSsttinqs 
8 d/1 s or 7 d/2 s 
7 data/1 stop 
8d/1s or 7d/2s 
7 data/1 stop 


Telephone 

286-9000 

286-9500 

286-4000 

286-4500 


Notes 

All these modems automatically set 
themselves for the correct speed. 
Only 8 are available. 

Only 4 are available. 


System Prompt. 

CALL, DISPLAY, OR MODIFY? 
DIALING nnnnn 
CALL COMPLETE 
Enter usemame> 

(rnisc. system messages) 
Locab 

(rrtsc. system messages) 
Username: 


You Type... 

CALL SISC <CR> [NOTE: If dialing from off-GSFC, you will 
see "ENTER NUMBER" instead! 

<CR> <CR> 

(type your name here) <CR> 

C DFTNIC <CR> 

NSINIC <CR> 


...via SprintNet (X.251 Links: Dial your local SprintNet (formerly Telenet) access number, then hit [RETURN] or 
[ENTER] several times until you see the prompt. (Information on local SprintNet access is available from the NSIUSO.) 
NOTE: If you are dialing in to SprintNet, you will need a NASA Packet Switched System (NPSS) DACS userid; contact the 
NSIUSO for more information. 


@ 

“CONNECTION ESTABLISHED* 


(misc. system messages) 


ENTER USERID> 
ENTER PASSWORD> 
ENTER SERVICE> 
(misc. system messages) 
Username: 


You Type... 

C NASA 
<CR> <CR> 

LOGON <CR> 

(your DACS ID) <CR> 
(your DACS p/w) <CR> 
DFTNIC <CR> 

NSINIC <CR> 


Questions and/or comments about the NSINIC may be e-mailed to the account name "NSIHELP" at any of the following: 
DECnet: DFTNIC (6148) TCP/IP: dftnic.gsfc.nasa.gov (128.183.10.3) BITNET: dftbit 

NASA Science Internet User Support Office 
Advanced Data Flow Technology Office 
Code 930.4 

NASA Goddard Space Flight Center 
Greenbelt, MO 20771 
301-286-7251 or FTS 888-7251 


The Internet Resources Guide 
and 

The Automatic Login Executor (ALEX) 


J. Patrick Gary 

Advanced Data Flow Technology Office 

Code 930,4 

Goddard Space Flight Center 


Presentation to 

NASA Science Internet User Working Group 

February 12, 1991 


INTERNET RESOURCE GUIDE 


NSF Network Service Center (NNSQ 
BEN Systems and Technologies Corporation 
10 Moulton Street 
Cambridge, MA 02138 
nnsc@nnsc.nsf.net 


Copyright Nodes 

The istemac Resaroe Goide is cospSsa by the NSF Network Service Center (nnsc@nnscjisf.net) at BBN System md 
Tedsaotogiat Cerjwraiioe from contributions by members of the Internet community. This work is supported by a 
wbwnsract with to IMvasity CorporatkJE for Atmospheric Research (UCAR), taida qsaxfiac rctasr agreement 
libs MiSiooal Sdeaoe FmmdUli©si (NSF). Tbs editor have mms. reamnahie efforts rs mmM& asms? hd kssm?Sm>^ hss. 
taeitSser UCAR, NSF,, NNSC oar BBN Is rsspcssfds for the acoiraey of to fissfop ia this goto. GopyriaM 19® 
BBN Systems sad Yechnsleiglei Carjwraitleo. 
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INTERNET RESOURCES GUIDE 

NUMBER OF ENTRIES 

IABL.E OF CONTENTS JULY 1980 JANUARY 199 1 


CHAPTER 1: 

COMPUTATIONAL RESOURCES 

18 

1 8 

CHAPTER 2: 

LIBRARY CATALOGS 

1 8 

21 

CHAPTER 3: 

ARCHIVES 

15 

18 

CHAPTER 4: 

WHITE PAGES 

5 

5 

CHAPTER 5: 

NETWORKS 

32 

36 

CHAPTER 6: 

NETWORK INFORMATION CENTERS 

5 

6 

CHAPTER M: 

MISCELLANEOUS 

8 

8 



Chapter 2: Library Catalogs 

A large number of libraries allow access to their library catalogs via the Interne! Such cata- 
logs can be very useful for finding uncommon books not available a s. local library. Ones a 
book is located, it can often be borrowed by your local library through Interilbraxy Lean. 
Another popular use of library catalogs is to check citations or references. Many catalogs also 
support more extended reference facilities. 

Please note that on-line catalogs often have a limited number of ports. Users arc asked not to 

abuse their access. 

We would like to acknowledge the considerable assistance of Ron Larsen, Art St. George, and 
Joe Sl Sauver in compiling this section. 


Contents 


Boston University (TOMUS) 

Univ. California and California Sl (MELVYL) 

Colorado Alliance of Research Libraries 

Research Libraries Information Network (RUN) 

Florida Center for Library Automation 

MIRLYN, The University of Michigan’s Online Catalog 

University of New Mexico Gateway 

Emory University Libraries Online 

Public Access Catalog 

MAGIC ..... ...... ... .... ....... ........... 

Info-Lib 



InfoTrax 

ARLO, The Library Catalog for the University of 

Colorado at Colorado Springs 

The Catalog of die University of 

Pennsylvania Libraries 

The University of Wisconsin 

Madison and Milwaukee Campuses 

Network Library System (NLS) — „ 

University of Utah library 

'Can! Catalog System _ — 

Northwestern University LUIS Online Catalog 

UR5US, Uni versify of Maine System 

Library Catalog — 

University of Illinois at Chicago 

NOTTS/LUIS 


2.1 

22 

2.3 

2.4 

2.5 

2.6 

2.7 

2.8 
2.9 

2.10 

2.11 

112 

113 


ZU 

113 - 
116 

117 

118 


May 29. 1990 


3NNSC 


Sedkalfl, Pige 1 
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MAGIC 


Address: 

Michigan State LT.: - - er?;:> Libraries 

East Lansing, MI 48824-1056 

E-mail: Thomas Albright, Head Library Systems: 20076tea@msu.bitnet 
Phone: 517-383-8700 (MSU Libraries Information/Reference) 


Description 

MAGIC is a computer-based library catalog of more than 1.3 million unique book, serial, 
microform, and other non-book titles in the Michigan State University Libraries. 

Network Access 

To access using IBM 3270 emulation: 

TN3270 to magic.msu.edu (35.8.2.99). 

At the VM 370 screen press the enter key. 

At the logon screen enter "Dial MAGIC". 

Press enter to get the MAGIC introductory screen. 

To exit from MAGIC, use your local escape sequence to return to the TN 3270 program and 
close the network connection. 

To access using Telnet (VT100, VT200 emulation): 

Telnet to merit.msu.edu (35.8.2.56). 

Enter "MAGIC" at the "Which Host?" prompt. 

Enter "VT100" as your terminal type. The MAGIC introductory screen will be displayed. 

To exit from MAGIC, press CTRL-E and then enter "%quit” 

Who Can Use the Resource 

MAGIC is available to anyone, without any restrictions. 

Miscellaneous Information 

For questions concerning network access contact: 

Computing Information Center 
MSU Computing Laboratory 
consult@ msu.edu 
(517) 353-1800 

For written instructions on how to use MAGIC, write to : 

MSU Libraries 
Information/Reference 
(517) 353-8700 


The information m this section is provided in accordance with the copyright notice appearing at the from cf this guide. 


February 21, 1990 


NNSC 


Section 2.9, Page 1 
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How to Get and Use 
the 

INTERNET RESOURCE GUIDE 


This README document contains, first, a discussion of the Internet 

Resource Guide, and then (for those who need them) , nitty-gritty details 
about PostScript files, FTP, and the Unix commands "compress," 
"uncompress," and "tar." 

The Internet Resource Guide hierarchy is organized as follows. 

Material is divided up into chapter and section. Each chapter has 
its own directory, and each section has its own files, one for 
PostScript and one for plain text. 

So, to retrieve section 1.1 of chapter 1, you should FTP the files 

resource-guide/chapter . 1/sectionl-l . ps (Postscript) 
resource-guide/chapter . 1/sectionl-l . txt (Text) 

To simplify retrieval of entire chapters and chapter updates, or of 
the entire resource guide, you can FTP compressed tar files. The tar 
files for individual chapters include the recently updated sections, and 
both the PostScript and text files. 

resource-guide/chapter 1 . tar . Z 

The most recent changes to a chapter are in a file named 
chapter#-changes . tar . Z . These include only the most recently updated 
sections ! 


B 


• The Internet Resources Guide (IRQ) is available 

via anonymous ftp from 
nnsc.nsf.net 

in the /resources -guide directory 

« The "How to Get and Use the XRG" README file 

is available 
via anonymous ftp from 


a) n nsc.nsf.net in the /resources -guide 
directory 'as file README 


directory as file README- res ource- 
guide 


359 


360 


Automatic Login Executor (ALEX) 


overview 

. Designed to perform remote logins to most resources listed in the Internet 

(1) 

Resource Guide. 

• Operates with menus, and provides a help screen. 

• Uses the telnet utility, so that the login is transparent to the user. 

( 2 ) 

• Implemented as "standalone" software which users copy and/or ftp to their 
workstation. 

• Written in two different languages, DCL and C shell, so that both VMS and UNIX 
based workstations can utilize it. 

• Also known as the Son of NICOLAS. 



As of duly 1990 

Assumes user workstation has TCP/IP-based telnet capability 


DCL Version 


gjsiifl Oflialan 


Written for VAX computers 
running VMS with MultiNet. 


Written for computers with the UNIX 
operating system. 


Total of 143 fifes. 


Total of 152 fifes. 


Main Driver is ALEX. 


9 Main driver Is alexu. 


Specialized comfiies to dear 
the screen, use a more utility, 

etc. 


Various executable flies that dear the 
screen, accept Input, etc. 


Remaining text and comfiies 
refer to a specific host. 


The remaining text and executables 
refer to a specific host. 


Version 1.0 codes for both the DCL and C shell versions were developed by 
James Landry/USRA/930.4 
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Top Menu of ALEX 


ALEX v.i.O -- Son of NICOLAS 
TOP MENU 

101 Source of Information 
[li Computational Resources 
(2 1 Library Catalogs 
131 Data Archives 
HI White Pages 
(51 Networks 

161 Network Information Centers 
[Ml Miscellaneous Resources 
|N| NICOLAS Connections 
f A 1 ALEX Access and Use 


iHjeip.lQluit . |Tlop - -> 
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Library Menu of ALEX 


ALEX v.t.Q — Son of NICOLAS 

Library Catalogs Menu 
(Aii of these choices to edify yourself} 

I2_0i| Boston University (TOMUS) 

12-02] Univ. California and California St. (MELVYL) 

I2_031 Colorado Ailiance of Research Libraries 
|2_04| Research Libraries Information Network (RL1N) 

12-051 Florida Center for Library Automation 

12-061 MIRLYN, The University of Michigan's Online Catalog 

1 2 — 0 7 1 University of New Mexico Gateway 

|2_08| Emory University Libraries Online Public Access Catalog 
I2_09| MAGIC 
12-10! Info-Lib 
|2_1 1 j InfoTrax 

|2_ 12| ARLO, The Library Catalog for U of C at Colorado Springs 
!2_13! The Catalog of the University of Pennsylvania Libraries 
|2_I4! U of W Madison and Milwaukee Network Library System (NLS) 
12-151 University of Utah Library Card Catalog System 
12-16) Northwestern University LUIS Online Catalog 
12-171 URSUS, University of Maine System Library Catalog 
12-181 University of Illinois at Chicago NOTIS/LUIS 


iHjeip.lQluit.lTlop -> 



Example of ALEX Selection 2 09 


ALEX Vo 1.0 ( JWL) ~ Son of NICOLAS 

Warning: 

It is very difficult to get out of MAGIC. 

Let the user beware, . . 

The people who designed MAGIC say the best way to get out is to tvoe 
Control E and then enter '%quit' . yP 

If you wish to leave, input ' e' . 

Press any other key to continue . . . 

to 

£ Okay, you asked for it . 

We' re going into MAGIC now. . . 

($ telnet 35.8.2.56 
MAGIC 
VT100 
$ exit) 



The Path of ALEX 















ALEX Availability 


® The file README-alex containing "Access and Use 
of the Automatic Login Executor (ALEX) is 
available via anonymous ftp from dftsrv.gsfc. 
nasa.gov in the /pub directory 

• The DCL version of ALEX for VMS systems is 

available 

1) via anonymous ftp from: 

a) dJ5tsrv.gsfc.nasa.gov in the /alex/dcl-alex 
directory 

b) dftnic.gsfc.nasa.gov in the alex directory 

2) via DECnet copy from: 

dftnic : : cldata : [ anonymous - ftp . files . alex] 

® The C shell version of ALEX for UNIX systems is 
available via anonymous ftp from 
dftsrv.gsfc.nasa.gov in the /alex/csh-alex 

•directory 
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NSI Conference Support 

Susan Aaron (NSI/Sterling Software) 

February 13, 1991 



NS1 Conference Subbsi! 


User Services Subaouo 


One of the many services NSI provides as an extension of customer/user support is to attend major scientific conferences. 

The conference effort provides NASA/OSSA scientists with many benefits. 

• Scientists get to see NSI in action. They utilize the network to read email, and have recently begun to demonstrate their 
scientific research to their colleagues. 

» Scientists get an opportunity to meet and interact with NSI Staff; most notably Customer Service Representatives. This gives 
scientists a chance to get status on their requirements, ask about network status, get acquainted with our procedures, and 
learn about our services. 

• Scientists are exposed to networking in a larger sense; particularly by learning about other NASA groups who provide 
valuable scientific resources over the Internet. 


u> 

o\ 

oo 


Susan Aaron 
NSI/Sterling Software 


page 1 
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NSI Conference Support 


User Services Subaoup 


A Perspective 

At first, there were minimal support mechanisms in place to conduct this endeavor. My job was to define, coordinate, and supervise 
the effort. 

First, we needed to decide what type of services we wanted to provide, along with how we wanted NSI to promote those services. 
Of course, we needed practical mechanisms to make it happen successfully. 

Goals in this area were: 

To develop a program under which NSI could provide the necessary support at major scientific conferences, including: 

• Defining support criterion 

• Defining strategies for promoting NSI services 

• Establishing practical mechanisms for success 


Support Criterion 

Basic criterion for attending conferences was established early in 1990 with supervision and direction from NSI Customer Service 
Manager Christine Falsetti. 

- There must be a large NASA/OSSA contingent. 

This ensures that we will be reaching our designated user communities. It also makes the effort more cost effective. 

- NASA disciplines request an NSI presence. 

When NSI is supporting a specific scientific project, we might be asked to attend a conference to highlight and support a 
particular scientific effort, (i.e.. Galileo, TOS) 

Because NSI has MOU's and requirements with all of the OSSA disciplines, we are getting more requests from Discipline and Division 
heads. . We are often directed to support a conference at the NASA Headquarters Program level. 


Susan Aaron 
NSI/Sterling Software 
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NSI Conference Support 


User .Services Subooup 


-j 

o 


2. Services 
- Educational Service 

NSI conveys its services at conferences by means of effective presentation materials, documentation, and informed booth 
participants. 

A large, freestanding backdrop is set up on which are mounted photos representing the scientific disciplines we are there to support. 
We now have two portable backdrops, and have a growing collection of display materials. NSI "stickers" depicting our logo are given 
away as freebies'. 

NSI has produced new documentation which describes the mission of the project and also provides information on how to use our 
services (and the Internet in general). 

A complete NSI bibliography has recently been developed which we make available to users at conferences. Follow-up after 
conferences involves mailing users the documents which were requested. (We have mailed over 4000 email matrices as of this 
month.) 

Documentation Includes: 


NSI brochure 

Electronic Mail Matrix 

Using the Interoperability 
Gateway 

Internet Resource Guide 

OSI in the NASA Science 
Internet- An Analysis 


NSI/NASA 
Joan Thompson 
Susan Aaron 

BBN Technologies 
Rebecca Nitzan 


Sterling Software 
Sterling Software 
Sterling Software 

Cambridge, Mass 
Sterling Software 


We are a regular contributor to the OSSA newsletter and have recently contributed major articles to EOS (magazine for the AGU) and 
the AAS newsletter. We are represented in all conference program announcements. 


Susan Aaron 
NSI/Sterling Software 
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NSI Conference Support 


User Services Subooup 


- NSI Staff Participation 

Customer Service Representatives play a major part in making the conference a success. Because they are the individuals most 
involved with specific scientific disciplines, they are the primary resource to impart information (like the status of requirements) to 
scientists who are in attendance at the conference. Their presence affords our users the chance to meet their advocates in person; a 
big help in establishing lines of communication. 

We also do a limited amount of informal training at the exhibit booth. An example of this is our instruction on how to use the 
Interoperability Gateway. 

NASA/NSI management also participate in conferences. 

At recent AGU and AAS meetings, special informational forums were conducted by Fred Rounds (Project Manager), Christine Falsetti 
(Customer Service Manager ),and Tony Villasenor (Program Manager). 


Susan Aaron 
NSI/Sterling Software 
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User Services Subaoup 


-Network Service 

Because we ere 3 service organization dedicated to providing NASA networking, it is appropriate for us to cre3te an environment 3t 
conferences that accurately reflects the service we provide. This means providing network access. ‘ 

NSI engineering is responsible for all the technical aspects of conference support; including network architecture, configuration and 
routing. Our installation group procures equipment, ships it to ihe conference site, and tests it before the conference We relv on our 
NOC for 24X7 coverage of the line at the conferences. 

NSI funds the necessary line procurement and coordinates with other NASA centers (where possible) and other organizations to 
ensure the line is dropped at the correct location and can be tested before the conference. 

NSI now provides network support at most conferences. Our basic service is to allow conference participants email access via the 

Internet; we bring a set of equipment to accommodate the customer requirement. 

Recently, we have provided networking as a value-added service to scientists and scientific organizations wishing to demonstrate 
databases, and now, image files via the network. This value-added service is evaluated at the Project and Program level and is 
provided on a case-by-case basis. 

Some, but not all, of the scientists supported this year are listed below; 


Dr. Tom Renfrow 

Planetary Data System (PDS) 

LPSC 4/90 

Dr. Chuck Acton 

pds/naifs Database 

LPSC 4/90 

Dr. Joy Beier 

NSSDC/NASA Master Directory 

AGU 12/89,5/90,12/90 

Dr. Michael Garcia 

Smithsonian Astrophysics Observatory 

AAS 6/90,1/91 

Dr. George Helou 

NASA Extragalactic Database 

AAS 6/90.1/91 

Dr. Elizabeth Bouten 

OCEANIC Database 

AGU 12/90 

Mr. Ted Clarke 

Galileo Earth Encounter 

AGU 12/90 

Dr. John Good 

Astrophysics Data System 

AAS 1/91 


Susan Aaron 
NSI/Sterling Software 
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NSI Conference gupoatt 


User Services Subaoup 


This year, NSI has successfully supported 13 conferences. The complete list follows: 
NSI Conferences Fiscal 1990-91 


Conference/Dlsclpllne Location Date Attendance Networking NASA Groups Supported 


American 

Geophysical 

Unton (AGU Fall Meeting) 
Multidisciplinary 
Space Physics 

San Francisco 
CA 

12/89 

6000+ 

yes 

modems/9.6 








Lunar Planetary 
Science Conference 
Solar and Planetary 

Houston TX 

3/90 

3000 

yes 

JSC Ethernet 
NSI routing 

PLDS 

NAIFS 

LPI 







PSCN Conference 

Networking 

Monterey CA 

4/90 

400 

yes 

modems/2400 

PSCN 







Geoinfo 
Life Science 

Montreal 

Canada 

5/90 

2000 


International Life Science 







AGU (Spring Meeting) 
Multidisciplinary 
Space Physics 

Baltimore MD 

5/90 

1000 

yes 

modems 

collaboration with NASA 
Master Directory 
(NSSDC) 







American Astronomical 
Society 

(Spring Meeting) 
Astrophysics 
Solar Physics 

Albuquerque 

NM 

6/90 

3000 

yes 

56Kbps 
NM Technet 

SAO 

NED 

(Sun Microsystems*) 
NASA Master Directory 


Susan Aaron 
NSI/Sterling Software 
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NSI Co nfe rwiea Symort 


User Services Subaoup 


MSI Conferences Fiscal 1990-91 


Conferenee/Disclpllne Location Date Attendance Networking NASA Groups Supported 


Evolution and Origin of Life 

Conference 

Life Science 

NASA Ames 

7/90 

300 

yes 

Ames Ethernet 
NSi routing 

SETI 







Division for Planetary 

Science 

Planetary 

Charlottsville 

NC 

10/90 

800 

yes 

56Kbps 

PDS 


■ 

■ 


■ 


AGU (Fall Meeting) 
Multidisciplinary 
Space Physics 

San Francisco 
CA 

12/90 

8000 

yes 
T 1 

Galileo 

OCEANIC 

NASA Master Directory 


■ ■ 

■ ■ 



H Hi 

American Meteorological 
Society 

Earth Science 

New Orleans 
LA 

12/90 

2000 


collaboration with NASA 
Master Directory 



■ 

■ 



AAS (Fall Meeting) 
Astrophysics 
Solar Physics 

Philadelphia 

PA 

1-91 

6000 

yes 

2 56Kbps 
UPenn 

r r . •/ - ■ 


■ ■ 



■ ■ 


NSI Users Working Group 
Networking 

San Mateo 
CA 

2-91 

150 

yes 

56Kbps 

X.500 White Pages* 

TGV, Incorporated* 

CRUSH 

COSMIC 

PLDS 

NSI Operations 







The Oceanography Society 
Earth Science 

St. Petersburg 
FL 

3/91 

1000* 

yes 
T 1 

NODS 

NODC 

NASA Master Directory 

NOAA 

AVHRR 

CZCS 


Susan Aaron 
NSI/Sterling Software 
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CRUSH: The NSI Data 
Compression Utility 

Ed Seiler (STX/GSFC Code 935) 
February 13, 1991 



CRUSH : The NSI Data Compression Utility 


CRUSH is a data compression utility that provides the user with several lossless 
compression techniques available in a single application. CRUSH was originally 
developed for the NSSDC as a result of requests for such a package from a users 
working group meeting. It is intended that the future development of CRUSH will 
depend upon feedback from the user community to identify new features and 
capabilities desired by the users. 

CRUSH provides an extension to the UNIX Compress program and the various 
VMS implementations of Compress that many users are familiar with. An 
important capability added by CRUSH is the addition of additional compression 
techniques and the option of automatically determining the best technique for a 

given data file. 

The CRUSH software is written in C and is designed to run on both VMS and 
UNIX systems. VMS files that are compressed will regain their full file 
characteristics upon decompression. To the extent possible, compressed files can 
be transferred between VMS and UNIX systems, and thus be decompressed on a 
different system than they were compressed on. 

Version 1 of CRUSH is currently available from the NSSDC. This version is a 
VAX VMS implementation. Version 2, which has the full range of capabilities for 
both VMS and UNIX implementations, will be available shortly. A VMS Backup 
file containing the source of version 1 is available at 

NSSDCB::ANON_DIR:[PUBLIC]CRUSH.BCK, and equivalently via anonymous 
FTP at NSSDCA.GSFC.NASA.GOV. It is anticipated that version 2 will be made 
available through the NSINIC. Watch for an annnouncement soon. 

CRUSH has been developed as part of the research of data compression 
techniques for the Configurable High-Rate Processor project at NASA Goddard 
Space Flight Center. Edward Seiler, of ST Systems Corp. is the developer of the 
software, and can be contacted via E-mail at 
SEILER@AMARNA.GSFC.NASA.GOV 
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CRUSH 

The NSI Data Compression Utility 


Features: 

• Compresses VMS and UNIX files, and keeps VMS file characteristics upon 
decompression 

• Can compress single files or entire directories 

• Extends the capabilities of the CMPR and COMPRESS programs 

• (Currently) provides 3 different methods, or automatic selection of the 
method that provides the best compression. More methods available soon 

• Compressed files can be recognized either from a file extension with _c 
appended, or by finding ASCII “CRUSHED” in first 7 bytes 

• Will decompress files that were compressed by UNIX COMPRESS 
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Usage Considerations: 


• Except for ASCII headers, compressed files are binary, so they cannot be 
printed 

• Three methods available: 

• Lempel-Ziv-Welch (LZW) : just as used in CMPR, it’s relatively fast 

• Witten-Neal-Cleary (WNC) : uses arithmetic coding 

• Adaptive WNC : usually slower than LZW but often compresses better 

• Automatic “method” tries each method for a file (or a sample section of a 
large file) and chooses the best one, but this may take a while 

• Decompressor figures out which method to use by itself 
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Usage 


CRUSH filename(s) 

• a single filename, a list of filenames, and wildcards may be used 

• user will be prompted if filename omitted 

• if file is named “myfile.dat”, compressed file will be named “myfile.dat_c” 

/METHOD = { Izw | wnc | adap | auto } 

• Izw : Lempel-Ziv-Welch 

• wnc : Witten-Neal-Cleary 

• adap : Adaptive WNC 

• auto : all of the above are tried 

/DELETE 

• delete “myfile.dat” after “myfile.dat_c” is created 
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/OUTPUT = filespec 

e CRUSH /OUTPUT=[mydir.dir] V compresses al! files and directs them to 
the subdirectory [mydir.dir] 

• CRUSH/OUTPUT=TT: directs uncrushed output to the terminal 


UNCRUSH filename 

• for a crushed file named “myfile.dat_c”, generates the uncrushed file 
“myfile.dat” 

/OUTPUT = filespec 

• UNCRUSH/OUTPUT=goofy.name myfile.dat_c renames the 
uncrushed file to “goofy.name” 



ELECTRONIC SOFTWARE SUBMITTAL / DISTRIBUTION 



L. Scott Clark 


Assistant Director 


sclark 

scott@cossack.cosmic.uga.edu 

(404) 542-3266 
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NASA 
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N9I-27034 

NASA MASTER OIRECTORY QUICK REFERENCE GUIDE 


1 . INTRODUCTION TO THE MD 


The NASA Master Directory (MD) la a free, online, multidisciplinary directory of space 
and Earth science data sets (NASA and non- NASA data) that are of potential interest to 
the NASA-sponsored research community. The MD contains high-level descriptions of 
data sets, other data systems and archives, and campaigns and projects. It provides 
mechanisms for searching for data sets by important criteria such as geophysical 
parameters, time, and spatial coverage. The MD also provides information on ordering 
the data. 

The MD is more than Just a directory, however. In order to simplify the process of 
finding more detailed information or accessing online data, the MD provides automatic 
connections to a number of data systems such as the NASA Climate Data System, the 
Planetary Data System, the NASA Ocean Data System, the Pilot Land Data System, and 
others. The MD provides general information about many data systems, data 
centers, and coordinated data analysis projects. It represents the first major step in the 
Catalog Interoperability project, whose objective la to enable researchers to quickly 
and efficiently identify, obtain information about, and get access to space and Earth 
science data. 

To learn how to get to the MD. see section 2. If you have trouble accessing the MD. or if 
you have questions regarding the NASA Master Direct o ry or Catalog Interoperability, 
please contact Jtm Thisman at (301) 286*9790 or jjy ^ (Set)? T4-S2H. 

Features of the MD include: 

• Capability of «*«whing for rft* sets by any combination of keywords (discipline, 
location, geophysical parameter), start void stop dates, spacecraft or data source, 
sensor, geographic coverage, scient i fi c p roject, and investigator 

• Easy-to-use mgmi. command, and screen- ferm interface that can be used wtth most 

terminal types smart and dumb terminals): 

• Displays of Hf including this. keywords, temporal and 

spatial coverage, archive information, data sec pe rs o nnel , and bibliographic 
references; 

• Displays of data ct"** including data center services, co nt a c ts, access 

procedures, available distribution media, and costa: 

• Displays of p r o j ect information such as scientifi c objectives, data 

charactensoce. and contact a: 

• Automatic to selected date systems or cat alog s through a simple UNK 

c omman d : and 

• HELP from every MD s c r ee n. 
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2. ACCESSING THE MO 


LOG ONTO THE NSSOC VAX 8650 


From SPAN nodes, enter SET HOST NSSOCA from the $ prompt and enter NSSOC at 
the Username: prompt (there is no password). 


Set your terminal to full duplex, eight bits, no'partty. one stop bit and 300. 1200. or 
2400 baud. Dial 301-286-9000. When the system responds with CONNECT 1200 (or 
300 or 24001. press return twice. At the ENTER NUMBER: prompt enter MO for the MD 
system, when you see the message CALL COMPLETE, press return for the Username: 
prompt. At the Username: prompt enter NSSOC (there is no password). 

Via Talnat 

From a Telnet node, enter TELNET NSISCA.GSfC.NASA.GOV or TELNET 
128.113.10.4 at the system prompt. Enter NSSOC at the Uaamama: prompt (there is 

no password). 


SELECT THE NASA MASTM DIRECTORY OPTION PROM THE N8S0C MENU 

(Option #1) 

The MD main menu will b« displayed. From this memi you cm select options to search 
for data set. data center, or project loCmutM (set the oou tree diagram at the end of 

the guides. 


SELECT A SEARCH OPTION FROM THE MO MAIN MENU 

Enter the number Mwaapwritag to the desired scorch optkm (data set data center, or 
project information searching). 


of poo® c^JAinn 
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3. DATA SET SEARCHING 


Data itUniSEM liaQ 

CHOOSE YOUR DESIRED SEARCH CRITERIA 

A search selection menu displays the available search criteria. Select the criteria that 
will identify data of interest !e.g.. if specflc geographic coverage a an important 
constraint to your data need, that would be one of the options you enter). It is usually 
better to begin a search with a minimum of criteria and then Later use more as 
necessary. When using a combination of criteria (e.g.. combining parameter keywords, 
sensors, sources, and temporal and spatial coverage), tt '3 strongly recommended that 
you include discipline (space physics. Earth science, etc.) as one of your criteria. This 
inclusion may help focus the results of your search. 

tf temporal or spatial coverage or investigator is not critical to your research needs, you 
may want to use the multiple keyword option, which allow® you to search all keyword 
fields (discipline, parameter, etc.) using several keywords. As AND or OR may be used 
in the query. There are no valid Lists available with the multiple keyword search 
nouon: so searching with the discipline, parameter, and location keywords might be 
better f you are unfamiliar with the MD. It is usually better to specify a few simple 
keywords or even parts of words (e.g.. MAO rather than MAGNETOMETER) rather than 
several compound keywords when using the word search option, which 13 nos, a full-text 
search system. 

After entering the desired search keys, the keyword entry form will be displayed,. 

ENTER THE DESIRED VALUES 

with smart terminals, your cursor will be positioned to the entry field; with line mode 
terminals, you will be prompted for the field vmhs®. Enter the value and pres® return. 

The cursor or prompt will then move to the a«£ field. Entering a ? wUl give a list of 
vaiid values from which a choice may be made. Once ail values are entered, the cursor 
or prompt will move to the COMMAND prompt. You can then enter SEARCH to start 
the search, or you can return to the fields to change a value by entering a penod or by 
pressing return. 

NOTE; The MD will return any values that match the characters entered. For example, 
if you enter NITR. values such u no. rogea, nitrogen dicssde. mete acid. etc., will be 
considered to match the specified criteria. 

Smfia_£dMdj_f2m 

Lists of valid values are available for the following Adda: 

Discipline Subdiscipline 

Parameter group Parameter 

Sensor (Instr ument) Saurc# (e.g.. spacscraftl 

Location Project 

When entering values in the®# field*, the MD will autttaatieaily check to see if the value 
entered is valid. If is is nee. a List of available values will be delayed, and you can 
select the number corresponding to the value of interesL If you do noc wans to select any 
of the values, enter EXIT to return to the entry form. Valids f«’ tome enters* (discipline 
and parameter keywords, and discipline and location keywords! are cross-vaUdat-- so 
that only combinations for which data set descriptions etost are displayed. When these 
criteria are combined with others such as sensor, source, or space and time coverage. 
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however. the use of valid Lists dees net guarantee that data set descr.ptlons matching 
the search cr.tena will be found m the MD. 

ENTER ’'SEARCH" TO SELECT DATA SETS 

Once you are satisfied with the cr.tena entered, move to the command Line (either using 
carnage returns or a per.cdl and enter SEARCH to retrieve data set information. 

Multiply Keyword Form 

If you cheese to search using the multiple keyword option, you can enter up to four 
keywords of any type (e.g.. sensor names, geophysical parameters, discipline keywords, 
spacecraft names). THERE ARE NO VALID LISTS AVAILABLE FROM THE MULTIPLE 
KEYWORD ENTRY FORM. The multiple word search defaults to searching for data sets 
with any of the keywords entered (a Boolean OR. e.g.. Wind OR Nimbus OR Ocaan ). 

You can change the OR value to an AND if you want to search frr data sets containing a 
specific combination of keywords (e.g.. Temperature AND Cloud AND Atrosois). 

Once you are satisfied with the cr.tena entered, move to the command line (either using 
carnage returns or a pertod) and enter SEARCH to retrieve data s information. 

ENTER “SEARCH" TO SELECT DATA SITS 

The system will search the data base for data set descriptions as soon as the search 
command is entered. A list of data set titles that match the keywords and/or enterta 
specified will be displayed. The total number of titles found will be displayed at the top 
of the screen. You can page through the titles by entering NEXT (or carnage returns): the 
current page and total number of pages will be displayed in the upper r.ght-hand comer. 

SELECT A TITLE OF INTEREST 

After looking at the titles, enter the number that corresponds to a data set of interest. 

To modify your search, enter EXIT to return to the previous leveL 

PRESS RETURN TO PAGE THROUGH THE INFORMATION 
OR ENTER DISPLAY FOR A MENU OP AVAILABLE DISPLAY SCREENS 

.After you select a title of interest, a brtef descrtptlon of the data set will be displayed. 

You can continue to eater carriage returns to page through the data set information. 
Available information is displayed in the following sections: 

Brtef Descrtptlon 

Data Set Attr.butes (keywords, coverage, spacecraft) 

Archive Information 
Data Set Personnel 
Bibliographic References 

You can use the DISPLAY command to display any of these sections or to see a menu of 
available screen display options. In some cases you can use the SUPPLEMENT 
command to display related data center or project information. 

[f the LINK command is displayed at the end of the command line, you can enter LINK to 
connect to the discipline directory, catalog, or inventory system to And out more 
information about the data set. When you log out of a remote system, you will be 
returned to the same screen from which you entered the LINK command. 

To select a new title, enter EXIT or D Q (for DISPLAY QUERY_RESULTS1. 
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4. SEARCHING FOR DATA CENTER/DATA SYSTEM DESCRIPTIONS 


After you select the data center search option from the MD main menu, an entry form 
will be displayed. Enter the common name (acronym) for the data center or data 
information system of interest (e.g.. N'SSDC. NODS. PDS. PLDS). For a list of available 
descriptions, enter ? and then enter the number that corresponds to your choice. 

After entering the data center or data system name, enter SEARCH to search for the 
information. Then select the desired option from the query resuits and page through 
the available information. Enter DISPLAY to view the available screen display 
options. 


5. SEARCHING FOR CAMPAIGN/PROJECT DESCRIPTIONS 


After you select the project information search option from the MD main menu, an 
entry form will be displayed. Enter the common name (acronym) for the scientific 
project of interest (e.g.. ISCCP. FIFE). For a list of available project names, enter ? and 
then enter the number that corresponds to the project of choice. 

After entering the project name, enter SEARCH to search for the project information. 
Then select the desired option from the query results and page through, the available 
information. Enter DISPLAY to view the available display options. 

6 . EXIT THE MO 


ENTER "QUiT_yD M WHEM YOU WANT TO LEAVE THE MD SYSTEM 

After being prompted for any comments, you will be returned to the NSSDC menu. You 
can then select the logout option from the NSSDC main menu. 
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A(C<e©qs (tlhiratmglhi ir©ll©jm©<ts 

Telenet's asynchronous dial-in services are available to 
PLDS users across the USA with either a local call or an 
IN-WATTS call (1-800-255-NASA). To use this service 
you must have a vulid NASA Packet Switch Network 
(NPSS) userlD & Password. Call your local PLDS user 
support office (Bee back) and they will file the paperwork 
to got your valid userlD and Password. It will take 
about 3 weeks for Marshall Space Flight Center to proc- 
ess the request and issue your userlD. When you get 
your ID the PLDS USO will explain how to access PLDS 
via Telenet. 

A<e«s©ss (tUnimuiigUa NASA Sasueiacs© 
Him1t©im©<ts 

TCP/IP: 

If your terminal haB access to the TCP/IP protocol, you 
can connect to the PLDS computers. Many national 
networks are interconnected. NSI is connected to a wide 
variety of TCP/IP networks such as NSFnet and is re- 
ferred to collectively as the Internet. 

At the prompt ($ or %) on each node, enter telnet and 
the name of the node given below. If the HOST UN- 
KNOWN message appears, at the prompt, try again 
using the number instead of the node name. At the 
USERNAME: or login: prompt, log on with pldsoryour 
assigned user account name. 

DECnet: 

Users with acceBB to NSI DECnet, formerly the NASA 
Space Physics Analysis Network (SPAN), can connect 
as follows: At the $ prompt, on VMS systems, enter SET 
HOST and the name of the PLDS node from the table 
below. If that fails try again using the DECnet number 
given in the table. 


Nods 

TCP/IP 

DECrwt 


N*m* 

Nod* NBR 

Nam* 

Nod* NBR 

ARC 

pldsal arc.na&a qov 

128 102 24 24 

pldsal 

24688 

GSFC 

pldsfl3 Qsfc.na&a qov 

128 163 104 6 

pld6g3 

6996 

III 

plds|2 jpl nasagov 

120 149 1 148 

pldsj2 

5642 
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Ordering/Price Policy 

Use of PLDS and data ordered from PLDS is free of charge 
to authorized scientists. Contact a PLDS user support office 
for authorization (see buck). Scientists muy request that 
data be sent to them on magnetic media, over the networks 
to their local computer, or to their disk space on a PLDS com- 
puter. Written format documents are sent upon request 
with all orders for digital data. 


User Support Office 

PLDS User Support Office 
NASA Goddard Space Flight Ctr. 
Code 934 

Greenbelt, MD 2077) 

(301)286 9761 
FTS 888 9761 

PLDSG3::PLDSUSO 

SUPPORT/GSFCMAIL 

pldsuso@pldsg3.gstc.nasa.gov 

PLDS User Support Office 
NASA Jet Propulsion Laboratory 
Mail Stop 183 501 
Pasadena, CA 91 109 

(818) 3546363 
FTS 792 6363 

PLDSJL.GEORGE 

geoige@pldsi2.jpl.nasa.gov 

PLDS User Support Office 
NASA Ames Research Center 
Ecosy6lom Set. & Tech. Branch 
Mail Slop 242 4 
Mottott Field, CA 94035 

(415)604 5947 
FTS 464 5947 

ECO :PLDS 

GLANGELICI/NASAMAIL 
gaiy@pldsat ate nasa gov 


Hours 


pldsg3, NASA Goddard Space Flight Center 
USO: 9:00 AM - 500 PM, Monday through Fnday 
Computer: 24 Houis, Monday through Sunday 
Computer Operator: 24 Hours, Sunday through Fnday 

pldsj2, NASA Jet Propulsion Laboratory 
USO: 900 AM • 4:00 PM, Monday through Friday 
Cotppuler: 24 Hours, Monday through Sunday 
Computer Operator: 7:30 AM • 3.00 PM (PacSic Time), Monday through Friday 

pldsat, NASA Ames Research Center 
USO: 8.00 AM - 400 PM, MOnday through Friday 
Computer: 24 Hours {Padlic Time), Monday through Sunday 
except 9.00 It :00 AM Monday 


1*U)S Project OITIn 

Code 934, Godded Space High! Ccnei 

Orccubdl, Maryland 20771 
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Description 

NASA’s Pilot Land Data System (PLDS) is a distrib- 
uted information management system designed to 
support NASA’s land science community. The PLDS 
provides a wide range of services including manage- 
ment of information about scientific data, access to a 
library of scientific data, a data ordering capability, 
communications, connection to data analysis facili- 
ties, and electronic mail. The PLDS provides these 
services by offering scientists the capability to search 
for and order data, and to communicate electronically 
with other scientists and computers. Three functions 
enable scientists to find what data are available and 
where they reside. The first two, Find data summaries 
and Read detailed descriptions give summary and de- 
tailed descriptions about data Bets or groups of related 
data sets, science projects, and institutions which 
archive land data. The third, gives information about 
specific pieces of data. This last function has two 
components, Search systemwide inventory andSearch 
Ureal inventory. The first component enables the user 
to find data elements (images, geological samples, 
transects,maps,etc.)thatcxiBt any where in the PLDS 
while the second has only information about data at 
the local site. The first enables the user to find pieces 
ofdata from several different dnta sets with the same 
temporal and spatial coverage and other elements 
common to most data sets, while the second allows the 
user to select a data set based on these descriptors and 
on those that are unique to a data set. 

The PLDS provides capabilities that enable electronic 
file transfers, intercomputer connection, and elec- 
tronic mail. Both TCP/IP and DECnet protocols are 
supported via the N ASA Science In ternet(NSI)- Access 
is also available through Telenet. 

To acquire data, users can place orders through the 
PLDS while logged on or they can call one of the Ubct 
Support Offices listed on the back. 

The scientific data and related descriptive informa- 
tion managed by PLDS come from several sources. 
These include four NASA land science projects (First 
ISLSCP Field Experiment (FIFE), the Inter-Discipli- 
nary Scicnces-Land Surface Climatology (IDS-LSC) 


project, the Sedimentary Basins Project (SBP), and the 
Oregon Transect Ecosystem Research Project (OTTER)), 
and several other data processing facilities, individual 
scientists and data systems. 

All information about specific pieces of scientific data has 
passed a check for internal consistency and typographical 
errors, in addition, information about the validity of the 
scientific data is also provided ifit was supplied with the 
data. 

Contents 


This account is for the infrequent user or the curious. 
Users wishing to place orders for data must have a 
personal account or be an authorized user. There are 
several ways to access the PLDS: Dial-in modems; 
Telenet; and NSI (TCP/IP or DECnet). 

Dial-in modems: 

Users can connect to PLDS through dial-in modems. 
300, 1200, and 2400 baud ratcB are supported by the 
data system. 

Stilling Preferred Value (nmiuminiutiiii n 


Data set 

SileLucatiun 

Aerial Photos (VIS, IR) 

ARC 

Airborne Sun Photometer 

ARC 

Aircraft SAR 

JPL 

AIS (Airborne Imaging Sj»cctromeler) 

JPL (future) 

Auto Meteorological Station 

GSFC 

AV1IRR (LAC) 

GSFC 

AVIRIS 

JPL (future) 

Daedalus (Thematic Mapper Simulator) 

ARC 

Digital Elevation Models 

JPL 

field Spectra (PIDAS. PPIIS) 

JPL (Future) 

Geological Samples 

JPL (future) 

MSS 

GSFC (f uture) 

NS-001 (Thematic Mapper Simulator) 
Polarization Differences Vegetation 

ARC, GSFC 

Index (PDV1) 

GSFC 

Snow Cover 

GSFC 

Spectra (FTIR, Beckman) 

JPL (Future) 

TIMS 

ARC, GSFC, JPL 

TM 

GSFC 


Access Procedures 


Mode 

Parity 

Bits per character 
Baud 

IVotocol 

Duplex 


ANSI 

liven (Disabled! 

7 1 8 when parity disabled) 
Equipment dependent either 3(X) or 
12(X) |24(X) is connection specific | 
X On/X Off 

Full duplex preferred; Equipment 
dependent 


Dial-in phone numbero: 


Site 
ARC Site 
GSFC Site 
JPL Site 


ELS 

464-7779 

88A9000 

977-6324 


Commercial 

(415)604-7779 
(301)286-9000 
(818) 393-6324 


ARer dialing a site follow the Bteps given below for that 
site. 

ARC: At the login: prompt, type plds or your 

user account name. If the login prompt 
docs not appear press the BREAK key 
until you get the prompt. 


There are three PLDS sites, one at the Ames Research 
Center in California, one at the Goddard Space Flight 
Center in Maryland, and another at the Jet Propulsion 
Laboratory in California. Scientists wishing to use the 
PLDS must have an account on a PLDS computer. To 
obtain an account you must be an authorized user. For 
details contact a PLDS user support office (sec back). A 
PLDS demonstration account (an account with limited 
privilcges)is availableatall PLDS sites, username plds. 


GSFC: Press the return key until the ENTER 

NUMBER: promptappears. Enter PLDS 
and press the RETURN key. At the 
CALL COMPLETE: prompt, press the 
RETURN key. At the USERNAME: 
prompt, logon with PLDS or your user 
account name. 

JPL: At the login: prompt, type plds or your 

user account name. 


I 


2 


1 


C. COSMIC 


405 




Software Catalog 
1991 Edition 
Diskette Format 


This Catalog may be copied and shared 


COSMIC 

The University of Georgia 
382 East Broad Street 
Athens, GA 30602 
Phone: (404) 542-3265 
Fax: (404) 542-4807 
E-Mail: COSMIC@UGA. (bitnet) 
SERVICE@COSSACK.COSMIC.UGA.EDU (internet) 
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I. Introduction 

This PC edition of the annual COSMIC Software Catalog contains descriptions of the over 1,200 com- 
puter programs available for use within the United States as of January 1. 1991. By using the PC ver- 
sion of the catalog, it is possible to conduct extensive searches of the software Inventory for programs 
that meet specific criteria. Elements such as program keywords, hardware specifications, source code 
languages, and title acronyms can be used for the basis of such searches. 

After isolating those programs that might be of interest to the user, It Is then possible to either view at 
the monitor, or generate a hardcopy listing of all information on those packages. In addition to the pro- 
gram dements that the user can search on, information such as total program size, distribution 
media, and program price, as well as extensive abstracts on the programs, are also available to the 
user at this time. 

Another useful feature of the catalog allows for the retention of programs that meet certain search cri- 
teria between individual sessions of using the catalog. This allows users to save the Information on 
those programs that are of Interest to them in possibly different areas of application. They can then 
recall a specific collection of progr ams for information retrieval or further search reduction if desired. 
In addition, this version of the catalog is adaptable to a network/ shared resource environment, allow- 
ing multiple users access to a single copy of the catalog database simultaneously. 

The enclosed disk contains all of the files and application programs necessary to install the COSMIC 
Software Catalog on a hard disk drive and/or a networked NETBIOS based environment. 


Il.Catalog Installation Instructions 


Before installing the catalog software and data, it 
is suggested that the user backup the distribu- 
tion disk with the DOS "diskcopy" command. In 
order to properly install the COSMIC Software 
Catalog, approximately 4.5 Mbytes of disk space 
is required. This provides for sufficient space to 
hold all information on CQSMIC's entire inven- 
tory as well as the software to access the data. 
However, this space can either be located on a 
local hard disk, or a network (shared access) 
drive. 

The user first must create a directory that will 
hold all the necessary files for the COSMIC 
Catalog. It is suggested that the directory be 
called "COSMIC" although it is not required. 

example: C> rod COSMIC 

After creating the directory (hereafter referred to 
as COSMIC) the user then moves to that direc- 
tory via the DOS "cd" command. 

example: C> cd \COSMIC 

Note that this directory may be located either on 
the user’s local hard disk or on a shared resource 
networked drive. 

The user then places the working copy of the 
COSMIC Catalog diskette into the appropriate 
local high density floppy disk drive. Nesn the user 
must make that floppy drive the current or 
logged drive. 


example: C> A: 

We now will use PKWARE's PKUNZIP utility 
(included on the catalog distribution disk) to 
install the data and program files in the desired 
directory. This is done by typing PKUNZIP, 
CATALOG (the name of the ZIP file containing the 
program and data files) and the name of the des- 
tination drive fC:' in our example): 

A> pkunzip catalog c: 

PKUNZIP will then display the names of the files 
as they are extracted from CATALOG.ZIP and 
placed in the default directory on the specified 
destination drive (C ACOSMIC' to our example). 

In order to conserve space on the distribution 
disk, several index files have been left off and 
must be generated before the program will func- 
tion properly. The user must now make the desti- 
nation drive and directory the (current working 
directory ('C:\COSMIC' in our example) by log- 
ging on to the drive specified in the PKUNZIP 
command line above: 

A> C : 

We will now Invoke the catalog program. 
COSMICAT, with a special command line option 
to generate the index files: 

C> cosmicat reindex 
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The program will notify you that it is creating the 
Index files .and will return you to the DOS prompt 
when It Is finished. You may now remove the 
working copy of the .catalog diskette and return it 
to a safe place or give it to a friend. If you 
encounter problems with any of the steps above, 
please feel free to call COSMIC at (404) 542-3265 
and we will help you resolve the situation. 

To complete the installation process, the user (or 
system administrator) must decide if the catalog 
will be used in a shared environment or not. If 
the catalog is to be used solely by an individual 
on his or her own system, no other installation 
procedures are necessary, simply jump to section 
HI on usage. 

If, however, the catalog is to be used in a network 
environment, some additional steps are neces- 
sary. First, the shared access location of the cat- 
alog must be determined. It is in this shared 
location that multiple users can simultaneously 
access the database flies (.DBT & .DBF) + index 
flies (.NTX) mentioned above, with optional 
shared access to COSMICAT.EXE. This location 
(shared drive name + pathname) must be typed 
in a single line ASCII text file called 
PATHNAME.TXT. It is also important to have this 
path name end in a backslash ("Yj character 
within the PATHNAME.TXT file for proper file 
name construction. PATHNAME.TXT will then be 
placed in the personal execution directory of all 
individuals who will be accessing the catalog. 
This personal execution directory is very impor- 
tant in using the catalog in a shared environment 
since the COSMIC Catalog creates temporary and 
semi -temporary files during the course of its 
execution. 

The personal execution directory should be 
located on the local hard disk (could also be a 
floppy, but that’s very slow) of the individual and 
should contain the following: 

1) The file PATHNAME.TXT containing the 
shared resource location of the catalog data flies 
(all .DBT, .DBF & .NTX flies). Note that this file 
can be created with any ASCII text editor. 

sind 

2) Either the executable portion of the catalog, 
COSMICAT.EXE or a batchflle which, when run, 
executes a shared version of COSMICAT.EXE 
through explicit pathname invocation. 

In eit ler cas> :, the current working directory 
during execution of the catalog must remain in 
the personal execution directory. 


For example, let us assume that the catalog data- 
bases, indexes, and the COSMICAT.EXE file have 
been placed in directory COSMIC on the Bhared 
network drive N:. Additionally, well assume 
that each user has created a personal directory 
named COSMIC on his/her local C: drive. Each 
user would then place an ASCII text file named- 
PATHNAME.TXT in their C:\COSMIC directory 
containing the single line: 

N:\CQSMIC\ 

For convenience sake, one might create a batch 
file In a directory that Is referenced by the DOS 
PATH environmental variable (usually a directory 
called something like DOS, UTILS, or BATS) 
named COSMICAT.BAT. This file might be 
created as follows: 

C>copy con: c:\bats\cosmicat.bat 

ECHO OFF 

CLS 

ECHO One moment. Invoking COSMIC catalog... 
C: 

CDNCOSM1C 

N:\COSMIC\COSMICAT 

(To terminate this input and return to the DOS 
prompt, type Ctrl-Z, and press the Enter key.) 

For any questions on the Installation process, 
feel free to call COSMIC at (404) 542 - 3265. 

III. Catalog Usage Instructions 

To begin a catalog session the user first must 
move to the directory containing the file 
COSMICAT.EXE (and the file PATHNAME.TXT if 
the database is to be located on a networked 
drive). To start the application, type "cosmicat" 
at the DOS prompt (C>). The application will then 
generate two successive screens with information 
on COSMIC as well as the address and phone 
number of COSMIC if further assistance is neces- 
sary. Pressing any key will move the user 
through these screens to the Main Menu. 

After the two introductory screens, the Main 
Menu screen is displayed. At this point, four dif- 
ferent activities are possible: 

The user can either: 1) Generate a screen or 
hardcopy listing of all possible keywords that are 
used in the Catalog: 2) Begin searching the 

Inventory for programs meeting user provided 
search criteria; 3) Generate a screen or hardcopy 
listing of all information on a particular program 
or programs: or 4) Exit the COSMIC Software 

Catalog and return to DOS. Pressing the appro- 
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plate key will then activate the activity desired. 
The following Is a brief discussion of each 
activity. 

A) List Ail Possible Keywords 

All programs in the COSMIC Inventory have been 
assigned an average of five different keywords 
selected from the NASA Thesaurus (NASA SP- 
7064). By selecting this option, the user is pro- 
vided a mechanism to list all unique keywords 
employed in the current catalog. This is useful in 
deciding upon search criteria for use in later 
inventory searches. When this option is selected, 
the user is prompted to choose either the printer 
(PRN:) or the screen as the output device. 

If the user selects the screen, an alphabetic list- 
ing of all keywords is sent to the monitor, one 
screen at a time. The user can then either suc- 
cessively view the proceeding screens (by press- 
ing "m"), or terminate the current listing and 
return to the Main Menu (by typing "x”). If, how- 
ever, the user chooses the printer as the output 
device, a continuous alphabetic listing of all key- 
words is sent to the printer Immediately. This 
listing is rather lengthy — printing in a vertically 
compressed mode will help save paper. As soon 
as the listing is complete, the user is returned to 
the Main Menu. 

B) Perform a Search on Inventory 

By performing successive searches on the 
COSMIC software inventory, the user is provided 
a powerful mechanism for isolating those soft- 
ware packages that directly apply to the user’s 
area of interest. Presently, searches can be done 
on four different information fields included with 
each program. When the Search Menu is first 
selected one of two possible situations will occur. 
Either the user will be prompted to select the 
field on which to search the entire inventory, or, 
if a past search produced a subset of pro-ams 
(retained in a file called HOLDSAVE.DBF located 
in the current working directory), the user will be 
asked to choose which group to search on (the 
entire inventory or HOLDSAVE.DBF). If the user 
chooses to use the entire inventory as the search 
base, the present HOLDSAVE.DBF file will be 
discarded (ie. deleted) in favor of generating a 
new subset file from the upcoming search. This 
gives the user the ability to manually (ie. through 
appropriate DOS commands) save the current 
HOLDSAVE.DBF file under a different file name 
(the HSFSN.NTX index file must also be saved in 
this instance as well) in order that the results 
contained in HOLDSAVE.DBF can be retained for 
future reference. By simply renaming the files 


back to HOLDSAVE.DBF and HSFSN.NTX within 
the COSMIC Catalog directory at some future 
time, the user can again recall these past results 
when using the catalog. 

The fields on which a search can take place: 

1) Titles & Acronyms; 2) Keywords; 3) Host 
Computer Types; and 4) Source Code Language, 
in addition, the user is given the option of return- 
ing to the Main Menu. All four search possibili- 
ties will prompt the user for a string of 
characters (NOT case sensitive) which will then 
be compared to the corresponding field of all pro- 
grams in the inventory (or a subset thereof). It 
should be noted that all searches look for the 
string provided by the user to occur anywhere 
within the field being searched. This allows for 
context searching of strings within fields. 

After typing a carriage return to terminate the 
search string (or <ESC> to cancel the present 
search), the text "....searching...." appears on die 
screen. The amount of time needed to search 
varies depending upon processor speed, as well 
as the search base being employed (entire inven- 
tory or HOLDSAVE.DBF subset). If the entire 
inventory was used for the search, the user is 
then prompted with the string "...One Moment 
Please..." while some file maintenance activities 
take place. 

As soon as these activities are completed (again 
time may vary with processor speed), one of four 
possible windows will appear. If NO programs 
were found satisfying the previous search condi- 
tion and the entire inventory was being used as a 
search base, the user will be prompted as such 
and will then be returned to the Main Menu. If 
the subset file HOLDSAVE.DBF was being 
searched and no programs were found, the user 
will be prompted as such with the current 
number of programs held to HOLDSAVE.DBF 
displayed as well. Since no programs were 
found, the HOLDSAVE.DBF subset file used as 
the previous search base will be: retained for any 
future searches. Again, to this situation, the 
user is returned to the Main Menu. 

When programs are found satisfying the search 
condition, a window appears displaying the cur- 
rent number found in the upper right hand 
comer. If the entire Inventory was used as the 
search base, the user Is then given three options: 
1) listing the program call-numbers and partial 
titles of all currently found programs to the moni- 
tor (one screen at a time, if necessary); 2) listing 
the same information to the printer; or 3) imme- 
diately returning to the Main Menu. Regardless 
of the option chosen, those programs found will 
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automatically be retained In the subset file, 
HOLDSAVE.DBF, for later searching and 

reduction. 

If, however, the search was performed on the 
HOLDSAVE.DBF subset file, the user Is 
prompted 'with a window displaying the current 
number of programs found, as well as the 
number of programs that were being held In 
HOLDSAVE.DBF prior to the search. The user is 
then given the option of replacing the HOLD- 
SAVE.DBF file with the newly found subset of 
programs for future searches; discarding the 
results of the last search In favor of retaining the 
search base just used (HOLDSAVE.DBF); or 
rejecting both the current results and the previ- 
ous HOLDSAVE.DBF search base In favor of 
using the entire Inventory for future searches. In 
all three cases, the user Is immediately returned 
to the Mata Menu after choosing an appropriate 
response. To further reduce the current 
HOLDSAVE.DBF, the user would again choose 
the Search option of the Main Menu. 

C) Output Results 

A most important aspect of any catalog Is the 
way In which information on particular items Is 
presented. The COSMIC Software Catalog for 
microcomputers has the ability to either browse 
Information on particular programs at the 
screen, or generate a hard-copy listing on the 
local printer. In addition, the user can manually 
enter the call numbers of the item to be dis- 
played, or use the programs held in 
HOLDSAVE.DBF as input Into the listing 
routines. 

When Output option Is chosen from the Main 
Menu and there is currently NO HOLDSAVE.DBF 
in existence, the user is prompted to manually 
enter the call-numbers of the program to be dis- 
played. The call-numbers consist of a three 
letter, 5 digit sequence of characters separated 
by a hyphen (-). The user can either type In the 
call number (followed by a carriage return <CR>) 
or simply press the <CR> to return to the Main 
Menu. 

If the call-number provided does NOT match any 
in the current COSMIC Inventory, the user will 
be informed of this fact and returned to the call- 
number entry window. Otherwise, the user Is 
then prompted for the device for output pur- 
poses; the monitor screen or the local printer. 
Choosing the local printer will send a complete 
listing of all Information on the selected program 
to the PRN: device. This Includes program size, 
distribution media, and program price, as well as 


a complete abstract on the program Itself. If, 
however, the user selects the monitor as the 
output device, the entire screen will be filled with 
all Information on the program. In addition, the 
user will be able to scroll through the program 
abstract window using the <UpArrow>, 
<D ownArro w> , <PgUp>, and <PgDown> keys. To 
finish browsing the abstract, simply press the 
escape key (<Esc>). You will then be returned to 
the manual call-number entry screen. 

If, however, a HOLDSAVE.DBF file exists, the 
user is given the option of either manually enter- 
ing program call numbers to browse (described 
above), or using the call numbers that have been 
saved In the current HOLDSAVE.DBF subset file. 
By selecting the option of using HOLDSAVE.DBF 
for browsing, the user is displayed successive 
program call numbers to act upon. For each call 
number presented on the screen, the user may 
either display the program information at the ter- 
minal, generate a hard copy listing of the pro- 
gram Information at the local printer, skip the 
particular program in question in favor of work- 
ing with the next sequential program call number 
held In HOLDSAVE.DBF. or exit the output activ- 
ity entirely and return to the Main Menu. 

Note that the programs stored In HOLD- 
SAVE.DBF will not be affected by returning to the 
Main Menu. 

D) Exiting The COSMIC Software Catalog 

Selecting this option cleans up all files and 
screen modes and returns the user to DOS. It 
should be noted here that If there was a HOLD- 
SAVE.DBF file generated or retained during the 
current catalog session, it and Its companion 
Index file, HSFSN.NTX will be retained in the cur- 
rent working directory and can be used during 
the next execution of the catalog software. 


If you have any suggestions on how to improve 
the catalog In future releases or have questions 
concerning the operation of this package, feel free 
to contact COSMIC. 
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Product Name: MultiNet, Version V2. 2 


Overview 

MultiNet " is a high-performance VAX/VMS multi-protocol networking environment currently supporting 
the TCP/IP family of protocols, the Xerox PUP protocol, and the CHAOSnet protocol. MultiNet sup- 
ports the entire family of TCP/IP services and devices. An NFS Client and an NFS Server are available 
as options. MultiNet includes all of the tools you need for any configuration, from an end-node system 
with a single Ethernet interface to a fully functional gateway with multiple interfaces and routing 
protocols. 

MultiNet uses state-of-the-art networking technology, utilizing the 4.3BSD TCP networking code run- 
ning in the VAX/VMS kernel environment. MultiNet communicates directly with user processes via a 
$QIO interface, and directly with VMS device drivers at the kernel level. MultiNet's kernel-implementa- 
tion of lightweight process threads delivers maximum application-to-application performance. 

MultiNet installs quickly, using the VAX/VMS VMSINSTAL utility. MultiNet's configuration utilities get 
you on the air quickly and painlessly. For example, the MultiNet Network Configuration Utility interact- 
ively customizes MultiNet to your network environment and then generates all configuration files and 
the startup command procedure. The MultiNet SET and SHOW utilities allow a system manager to 
examine the state of the network, and examine and modify the MultiNet configuration without 
rebooting. 

VMS users and system managers adapt quickly to the MultiNet environment and its services. All 
MultiNet applications and configuration management utilities include VMS-style interfaces with DCL 
commands, VMS HELP library entries, and clear, logical prompts. Additionally, MultiNet includes 
DECwindows support, providing users the ability to run DECwindows applications over TCP/IP in 
addition to DECnet. 

Supported Configurations 

MultiNet supports DIGITAL’S VAX and MicroVAX computers in any valid VMS configuration. MultiNet 
runs under VMS versions from V4.5 and upward, and uses spinlock synchronization to support Sym- 
metrical Multi-Processing (SMP) under VMS V5. 

Supported Devices 

Typically MultiNet is used with the DEC-supplied Ethernet controller provided with your VAX hard- 
ware. MultiNet supports all DEC Ethernet controllers using a standard kernel-level interface into any 
VAX/ VMS Ethernet driver. Using the driver's multiplexing features, MultiNet can share the controller 
with other protocols; for example, DECnet, LAT, and Local Area VAXclustering. Up to ten such 
Ethernet controllers per machine are supported. 

MultiNet also supports the following network devices: 

• ACC's LH-DH ARPAnet controller 

• ACC's ACP-5100 and ACP-6100 HDLC T1 controllers 

• ACC's ACP-5250 and ACP-6250 X.25 controllers 

The ACP-5250 and ACP-6250 may be used to connect to the Defense Data 
Network PSNs 

• CMC's ENP family of Ethernet controllers 

• Symbolics' CHAOSnet 4-Megabit controller 

• IMP1 1 -A ARPAnet controller 
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• DEC'S DMR-1 1 . DMC-1 1 , and DMV-1 1 DDCMP controllers 

• 3-Com's Ethernet controller 

• Xerox's 3-Megabit Ethernet controller 

• Excelan's EXOS UNIBUS and Q-bus controllers 

• NSC’s P1 13/1 4 Hyperchannel controller 

• Interlan's Nil 010 Ethernet controller 

• SLIP (Serial Line IP) using any VMS supported terminal multiplexer 

• Proteon's proNET-10 and proNET-80 Token-Ring controllers 

In addition, when MultINet \s configured to use more than one network device, it can serve as an IP 
gateway between those devices. 

SERVICES 

All inbound network connections are handled by the MultINet Master Server process. This process is 
responsible for accepting or rejecting a connection, and for either performing or invoking the 
requested service. Using the Server Configuration Utility, the system manager can enable, disable, 
and add new services to the Master Server's configuration. The system manager can also have the 
Master Server restrict IP host and network access on a per-service basis. The Master Server can keep 
an audit trail of attempted, accepted, and rejected connections, which can be enabled on a per-service 
basis. The Master Server can log the times, source addresses and names, and the services 
requested. 

MultINet supports each of the following standard protocols. Unless otherwise stated, both client and 
server forms are supplied. 

DOMAIN NAME SERVICE (RFC1034, RFC1035, RFC1 101) 

MultINet provides Domain Name Service using Berkeley's BIND 4.8.1 nameserver running 
internal to the Master Server. No separate process slot is required, eliminating some 
scheduling overhead. BIND can function either as a caching-only nameserver to assist the 
resolver, or as a fully functional primary and secondary nameserver that advertises information 
about the hosts on your network. Domain Name Service under MultINet also supports 
encoding of network names and numbers according to RFC1 1 01 . The NSLOOKUP utility is 
provided to assist in tracking and degugging Domain Name System configuration problems. 

All user utilities translate names to internet addresses using Domain Name Service. 

MultINet also supports the standard RFC952-format host tables, offering exceptionally rapid 
access. Instead of directly accessing the ASCII host table file, MultINet compiles it, using a 
perfect-hashing scheme, and installs it in a global section. The host table scheme can be 
used in conjunction with Domain Name Service, allowing failed Domain Name System queries 
to be converted to host table lookups before being returned to the user. 

TELNET (RFC854, RFC855, RFC856, RFC857, RFC1041 , RFC1073, RFC1079, RFC1080, 
RFC1091) 

MultINet's TELNET virtual terminal utility provides login access between your machine and 
any other node on the IP network. Access through the network is quite transparent because 
the TERMINAL TYPE, WINDOW SIZE, DYNAMIC FLOW CONTROL, and BAUD RATE options 
are supported and negotiated automatically. MultINet's TELNET client also supports the 
TN3270 protocol allowing VMS users to access IBM mainframes as a 3270 block mode 
terminal. The TELNET server directly connects the TCP network kernel to the VMS terminal 
class driver, providing efficiency on par with LAT or directly-connected devices. As there is no 
limit on the number of incoming TELNET sessions, and only about 500 bytes of memory are 
required per connection, MultINet is ideally suited for terminal-server applications with 
hundreds of incoming sessions per machine. 
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DECwindows 


MultiNet's DECwindows support provides users the ability to run DECwindows and X windows 
applications over TCP/IP in addition to DECnet. This support allows users to run applications 
between VMS systems and non- DEC computer systems that support X windows over TCP/IP. 
MultiNet supports DECwindows by providing a $QIO interface that emulates DEC'S VMS/ 
ULTR1X Connection (UCX) product, effectively making DECwindows think it’s running over UCX. 

FTP (RFC959) 

The File Transfer Protocol (FTP) utility provides high-speed reliable transportation of files. 
MultiNet's FTP includes two noteworthy extensions to the standard FTP protocol. A special 
mode pro-vides transparent and efficient transportation of any FILES-1 1 file (e.g., ISAM- 
indexed files) between any two VMS machines. Another extension provides on the fly 
Lempel-Ziv (L-Z) compression between the client and server to minimize network traffic, at the 
expense of additional host overhead. L-Z compression effectively increases the bandwidth 
of slow lines by 30-100% (typically 60-70%). 

The FTP Server uses the standard VMS LOGINOUT utility for account validation and setup, 
thus fully supporting all related VMS security features such as ACLs, accounting, auditing, 
and break-in detection and evasion. 

SMTP (RFC821 , RFC822, RFC974) 

MultiNet includes a Simple Mail Transfer Protocol (SMTP) mail system which interfaces to the 
VMS MAIL utility or the MM mail user interface, allowing VMS users to send and receive SMTP 
mail transparently. Outgoing mail is submitted to a VMS queue, where the Mail Symbiont 
immediately attempts delivery, and in the event of a network failure, requeues the mail for later 
delivery. When using VMS MAIL, all standard features are supported, including SET 
FORWARD and address aliasing. The MultiNet SMTP mail system itself supports an easy-to- 
configure address alias and mailing list database. 

MM 

The MM utility provides an alternative to VMS MAIL for electronic mail users. MM offers several 
useful features not available under VMS MAIL, including: the ability to save and restore mes- 
sages before sending them; the ability to create user-defined headers; and a sophisticated 
message filing and manipulation scheme. MM can be used to send both SMTP and DECnet 
mail. Additionally, the MM utility can be used to send mail via the PMDF electronic mail gateway 
system available from Innosoft International, Inc. 

RPC and NFS (RFC1057, RFC1094) 

MultiNet includes the Sun Microsystems developed public-domain remote procedure call 
(RPC) library to allow users to develop their own RPC-based applications. MultiNet also 
includes the RPC Port Mapper and the RUSERS (display users logged-in to remote systems) 
and RWALL (broadcast a message to all users on remote systems) services. 

The optional MultiNet NFS Client allows VMS applications to transparently access files stored 
on NFS servers. The NFS Client can remote mount file systems on ANY system having an 
NFS server. The NFS Client device driver provides a standard file system interface and is 
called automatically by the normal VMS Record Management Services (RMS). Remote NFS 
servers supporting full UNIX (NFS) file system semantics appear to VAX/VMS systems as fully- 
functional Files-1 1 ODS-2 file systems. This includes support for multiple file versions and 
arbitrary VMS (RMS) file attributes. Files created on the server system appear as Stream_LF 
files to the local VAX/VMS system; text files created by the local VAX/VMS system appear as 
normal "Stream" files on the server; and other VAX/VMS file types are stored on the NFS 
server as "raw" VMS data blocks. This permits other VAX/VMS clients to share these files on 
the NFS server and non- VMS systems to access the data, provided the non- VMS systems are 
capable of interpreting the "raw” VMS data blocks. 
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The optional MultiNet NFS Server is a high-performance server implementation of the Net- 
work File System (NFS) standard developed by Sun Microsystems. The NFS Server maps the 
complete UNIX file system semantics onto the VMS file system, including symbolic and hard 
links and device files, making a VMS file system look exactly like a UNIX file system. All VMS 
text files are type-converted to look like UNIX stream files for maximum interoperability. The 
NFS Server uses a file and directory cache between the file system and the network, to mask 
VMS bottlenecks from the requesting UNIX machine. The NFS Server runs in the kernel and 
uses a proprietary XDR serializer to move data directly between the file system cache and the 
net-work buffers. By default, the cache functions as a write-through cache, but it can be 
configured as a write-back cache to increase performance. The NFS Server can export all 
Files-1 1 ODS-2 VMS volumes, including shadow sets, bound volumes, and DFS-served disks. 
The NFS Server distribution also includes a PC-NFS authentication and print server 
(PCNFSD). It allows PCs and compatibles running PC-NFS client software to access NFS 
served filesystems as though they are local DOS disk drives. PCNFSD supports printing from 
PC clients to VMS print queues. 

REMOTE PRINTER SERVICES 

An LPD client and server allow MultiNet users to access printers on remote UNIX computers, 
and allow the UNIX users to access printers connected to the MultiNet computer. The LPD 
server transparently makes VMS printer queues appear to remote UNIX users as local printers. 
The VMS system manager can use the Server Configuration Utility to grant or deny access to 
the VMS machine’s printers. 

The LPD client runs as a VMS Print Symbiont. VMS users use the native VMS PRINT com- 
mand to print files transparently to remote UNIX machines. The system manager uses the 
Printer Configuration Utility to automatically configure, initialize, and start these special VMS 
printer queues. 

UNIX "R" SERVICES 

MultiNet includes the popular UNIX "R" services RSHELL, REXEC, RCP, RLOGIN, and RMT. 

The RSHELL utility allows VMS users to remotely execute commands from the VMS command 
line, either by specifying a password, or by using access based on previously provided cre- 
dentials. Likewise, the RSHELL and REXEC servers allow remote users to execute DCL 
commands directly from their command interpreters, a shell for UNIX users and DCL for VMS 
users, 

MultINet's RCP client and server allow users to copy files between systems on the network. 
MultINet's RCP supports the recursive copying of directory trees between systems, and the 
transparent transfer of all VMS file types (e.g., ISAM-indexed files) between VMS systems 
running MultiNet. 

MultINet's RLOGIN provides an alternative to the standard TELNET for remote virtual terminal 
access. RLOGIN is an ideal protocol for communication with UNIX machines. RLOGIN includes 
support for dynamic window sizing and dynamic flow control negotiation and will pass the 
terminal type and speed to the remote server. Like the MultiNet TELNET Server, the RLOGIN 
Server directly connects the VMS terminal driver to the network. 

MultINet's Remote Magtape Server (RMT) allows UNIX users to access your VMS tape drives 
via the network. The UNIX system manager can use the "rdump" and "rrestore" utilities to 
backup a UNIX system via the network to a VMS tape drive. 

TALK 

The MultiNet TALK utility is a VMS PHONE-like utility that allows users to communicate with 
users of other systems that support the TALK protocol. Like VMS PHONE, TALK provides a 
split-window screen, with one window displaying what one user types, and the second 
displaying what the respondent types. For maximum interoperability, both the 4.2BSD "Old 
Talk" and 4.3BSD "New Talk" protocols are provided. 
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Network Time Protocol (RFC1059) 

MultiNet supports the Network Time Protocol (NTP). NTP provides a mechanism to synchro- 
nize and coordinate time distribution in large, diverse LAN or WAN environments. Once 
configured, NTP automatically polls other NTP clock servers and uses complex estimations of 
the network delay to determine the local time to accuracies approaching ten milliseconds. As 
clocks drift apart, NTP initiates a clock skew, running the VMS clock 1 0% faster or slower until 
the time drifts back into synchronization. 

With a few WWVB-synchronized NTP servers on your network (such as the servers on the 
DARPA Internet), NTP can synchronize all of your VAX clocks. 

FINGER (RFC742) 

MultINet's FINGER utility provides a status report about the users of a system. Because 
FINGER is supported in both client and server form, it can also supply status reports about the 
users of remote systems. 

WHOIS (RFC954) 

MultINet's WHOIS client is provided to access the Internet's network-wide user directory 
service, which is maintained by the DDN Network Information Center (NIC) at SRI International, 
on behalf of the Defense Communications Agency (DCA). WHOIS can deliver the full name, 
U.S. mailing address, telephone number, and network mailbox for any DDN user registered in 
the NIC database. 

NETSTAT 

The MultiNet NETSTAT utility displays detailed information from a remote machine, including 
the current configuration and operation of the network. 

SYSTAT (RFC866) 

The MultiNet SYSTAT Server allows remote users to display the output of a VMS "SHOW 
SYSTEM" command. 

BOOTP (RFC951 , RFC1084) 

MultiNet supports the BOOTP protocol, using V2.1 of BOOTP. BOOTP runs internal to the 
Master Server and quickly responds to booting diskless nodes requesting their boot param- 
eters. BOOTP supplies the booting node with its Internet Address, Gateway, and other 
information it needs to configure and load. 

RARP (RFC903) 

MultiNet supports the Reverse Address Resolution Protocol (RARP) to provide booting 
diskless workstations their Internet (IP) addresses. 

TFTP (RFC783) 

MultINet's Trivial File Transfer Protocol is provided in both client and server form. The TFTP 
server generally is used only for booting diskless workstations (because FTP provides a 
superior and more sophisticated file transfer protocol). TFTP's lack of authentication has 
traditionally posed a security problem for system managers needing to run TFTP. Since, 
however, the MultiNet Server Configuration Utility can be used to limit the machines which can 
access the TFTP server, and the MultiNet Network Configuration Utility can be used to limit 
access to a particular directory tree on the server, the MultiNet TFTP server can be used to 
provide boot services without threatening system security. The MultiNet TFTP client is an 
invaluable tool for debugging TFTP server problems. 
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SNMP (RFC1066, RFC1098) 


MultiNet has support for a Simple Network Management Protocol (SNMP) agent, which 
answers queries for information such as interface status, protocol statistics, and routing 
information. SNMP runs internal to the Master Server and quickly responds to queries for 
information from SNMP management stations. 

GATEWAY ROUTING PROTOCOLS 

MultiNet provides support for the EGP (RFC91 1), RIP (RFC1058), and HELLO routing proto- 
cols using GATED Version 1 .9. GATED runs internal to the Master Server process, and there- 
fore does not occupy a separate VMS process slot. Through a configuration file, the system 
manager can configure GATED to dynamically discover all routing information, and subject to 
any administrative restrictions, choose the best route to each network. GATED is always watch- 
ing for changing network conditions (such as a failing gateway), and when IP traffic must be 
rerouted, GATED directly manipulates the MultiNet routing tables to effect the change. 

NETCONTROL 

The NETCONTROL server runs internal to the Master Server and allows the VMS system 
manager to control other services that run internal to the Master Server. Normally NETCON- 
TROL can be accessed only from the local node, but if the default restrictions in the Server 
Configuration Utility for this service are eased, access can be allowed from any machine on 
your network. The NETCONTROL client includes a DCL command interface that offers the 
system manager direct and simple control of the various services. For example, to reload the 
Domain Name Server database: 

$ MULTINET NETCONTROL DOMAINNAME RELOAD 


DIAGNOSTIC TOOLS 

The MultiNet PING utility allows MultiNet users or the system manager to diagnose network 
problems by measuring the packet loss rate and delay to any node on your network. PING 
uses an ICMP ECHO request to bounce packets off of the target node. 

The MultiNet TCPDUMP utility allows MultiNet to function as an Ethernet protocol analyzer 
to assist in debugging of network or protocol problems. TCPDUMP is only supported on DEC 
Ethernet controllers. 

The MultiNet TRACEROUTE utility allows the MultiNet system manager to dynamically 
determine the current topology of the network to which he is connected. TRACEROUTE 
sends UDP packets with increasing Time-To-Live values, and examines the resulting ICMP 
TIME EXCEEDED returns to discover each intermediate gateway to the target node. 

MultiNet includes TCP and UDP variants of the important diagnostic services CHARGEN, 
DAYTIME, DISCARD, ECHO, and TIME for debugging potential network problems. 

CHAQSnet Services 

MultiNet includes QFILE and RTAPE servers that give Lisp Machines access to the VMS file 
system and the VMS tape drives. A CHAOSnet TELNET client and server allow remote logins 
to Lisp machines that are not also running TCP/IP. NAME, TIME, and UPTIME servers are also 
provided. 

PUP Services 

In addition to PUP TELNET client and server for remote login, MultiNet provides the LEAF 
protocol remote file access and Gateway and Name lookup services. 
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Support for Non-DEC Terminals 

All MultiNet utilities use the standard VMS SMG$ routines to access display terminals. Any non-DEC 
terminal the system manager adds to the VMS TERMTABLE definitions file is fully supported by all 
MultiNet utilities, including the TELNET and RLOGIN TERMINAL TYPE negotiations. 

DECNET INTEROPERABILITY SERVICES 

In addition to sharing a DEC Ethernet controller side-by-side with DECnet, MultiNet allows layering of 
the IP and DECnet protocol stacks. 

DECnet-over-IP allows the system manager to use the DECnet Circuit Configuration Utility to 
configure a point-to-point DECnet circuit between any two MultiNet machines across an arbitrary IP 
network. This feature is ideal for providing DECnet connectivity across an IP-based LAN or WAN, 
especially when the alternative is to build the entire network with dual-protocol routers or duplicate 
communications hardware. Once the DECnet circuit between two MultiNet machines is established, 
any DECnet machine can use it. 

IP-over-DECnet allows the system manager to use the Network Configuration Utility to configure a 
point-to-point IP connection between any two MultiNet machines across an arbitrary DECnet 
network. Like DECnet-over-IP, this feature can provide IP connectivity where DECnet connectivity 
already exists. 

PROGRAMMING LIBRARIES 

MultiNet includes a $QIO interface that offers the VMS programmer full access to the asynchronous 
I/O features of VAX/VMS. For compatibility with applications developed for 4.3BSD UNIX, MultiNet 
also provides a shareable 4.3BSD-compatible socket library and an RPC library based on Sun's public 
domain RPC. These libraries are also used by programmers who do not require all of the asynchro- 
nous I/O features of $QIO. 

Extensive online help (under HELP MULTINET PROGRAMMING) is available documenting the 
features and calling sequences of the $QIO interface and the 4.3BSD-compatible socket calls. For 
compatibility with applications developed for Excelan's EXOS product line, an EXOS-compatible $QIQ 
interface is provided. For compatibility with applications developed to run over DEC'S VMS/ULTRIX 
Connection (UCX) package, a UCX-compatible $QIO interface is provided. 

DOCUMENTATION 

MultiNet documentation includes: 

• Release Notes 

• Introduction to MultiNet 

• MultiNet Installation Guide 

• MultiNet Users' Guide 

• MultiNet System Administrators' Guide 

• MultiNet Programmers' Reference Manual 

• MultiNet NFS Server System Administrators’ Guide 

• MultiNet NFS Client System Administrators' Guide 

SUPPORT 

MultiNet support services include hotline sen/ice. updates, and remote diagnosis. The first 90 days 
of support are included in the product warranty. An annual maintenance agreement may be 
purchased to extend the support period. 
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PREREQUISITE SOFTWARE 

VAX/VMS V4.5 or later 

OPTIONAL SOFTWARE 

NFS/PCNFSD Server tor MultiNet 
NFS Client for MultiNet 

LICENSING 

MultiNet is available under license from TGV, Incorporated, or a TGV-licensed OEM or distributor. For 
pricing and licensing information, contact your authorized MultiNet distributor or TGV, Inc. at 603 
Mission Street, Santa Cruz, C A 95060; call TGV at (408) 427-4366 or (800) TGV-3440; or by FAX at 
(408) 427-4365. 

MEDIA 

MultiNet is distributed on 1600 BPI magnetic tape or TK50 cartridge. 


MultINat Is a trademark of SRI International and of TGV, Inc. 

VAX, VMS. Micro VAX, DEC, DECnet, and DECwindows are trademarks of Digital Equipment Corporation. 
UNIX Is a trademark of AT&T. 

Symbolics and CHAOSnet are trademarks of Symbolics, Inc. 

Xerox and PUP are trademarks of Xerox Corporation. 

ACC Is a registered trademark of Advanced Computer Communications. 

ENP Is a trademark of Communications Machinery Corporation. 

Excelan and EXOS are registered trademarks of Novell. Inc. 

4.2BSD and 4.3BSD are trademarks of me Regents of the University of California. 
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IGV premieres first NFS client software 
for VAX/VMS systems 


By Steven Kovsky 

SANTA CRUZ, Calif. — 
The first software that per- 
mits VAX machines running 
VMS to connect as clients to 
Unix servers running NFS 
will become available next 
month from TGV. 

NFS Client for VMS rep- 
resents a breakthrough for 
VMS users who have been 
shut out from sharing files 
with Unix-based file servers 
that run NFS (Network File 
System), Sun Microsystems’ 
file directory system, which 
has become a de facto stan- 
dard in the industry, accord- 
ing to David Kashtan, inven- 
tor of NFS Client for VMS. 

The NFS client software 
for VMS will give VAX users 
access to both Unix servers 
and VMS servers for the first 
time. 

Kashtan and Kenneth 
Adelman, formerly software 
developers at SRI Interna- 
tional of Menlo Park, Calif., 
founded TGV (Two Guys 
and a VAX) in 1988. 

While still at SRI, Kashtan 


developed Eunice, "the first 
true Unix emulation for 
VMS," Kashtan said. 

The Eunice project was 
followed by Kashtan 's devel- 
opment of what TGV offi- 
cials claim is the first TCP/ 
IP-compatible networking 
software for VMS. This latter 
SRI product, called Multi- 
Net, became TGV's first 
offering shortly after the 
company was formed, Kash- 
tan said. 

The iniuai release of the 
NFS Client for VMS offering 
will require that MultiNet. 
which puts TCP/IP net- 
working protocols on VMS, 
reside on the VAX . 

According to TGV's Kash- 
tan, NFS Client for VMS is 
based on a carefully crafted 
‘'pseudodriver" that emu- 
lates VMS' extended 
queued I/O, ancillary con- 
trol process (XQP/ACP), 
which allows files on the 
NFS server to appear to the 
VAX user like the contents 
of a locally installed DEC 
disk drive. 

The NFS client software 


transparently converts the 
semantics of the VMS file 
system directly to NFS-com- 
pauble calls, Kashtan said. 

The process of matching 
VMS clients with NFS hosts 
has proved so complex that 
Kashtan doesn't believe any 
competitor is close to pro- 
viding a similar software 
product. 

"It’s not a situation 
where we have a two- or 
three-month lead before 
someone else releases a 
compeduve product,” Kash- 
tan said. "The degree of dif- 
ficulty is such that others 
who have tried [to develop 
it] have given up." 

NFS Client for VMS will 
be priced at about $500 for 
VAXstadons, and could be 
higher for other VMS com- 
puters, officials said. Muld- 
Net for VAXstadons or VAX- 
servers is priced at $1,200. 

Kashtan said the initial 
version of NFS Client for 
VMS will support File and 
record locking only to the 
extent that RMS does. The 
software will not allow a 


VMS client to connect to a 
VMS host via NFS, he said. 

Full record locking to come 

Full record locking and 
access to VMS hosts via NFS 
are expected in the next 

release, Kashtan said. 

As an opdonal adjunct to 
Multi.Net, TGV markets NFS 
Server, which lets NFS 
clients access VMS-based die 
servers:. 

TGV has also announced 
a trade-in program for 
MultiNet. Customers can 
receive a credit of as much 
as 50 percent toward the 
purchase of MultiNet in 
exchange for any other 
board-based or host-based 
TCP/IP impiementauon for 
VMS, said Paul Rasmussen, 
TGV’s general manager. 

Prices for MuldNet range 
from $1,200 for VAXstadons 
to $24,000 for the VAX 9000 
Model 210. 

For additional information, 
TGV Inc. can be contacted at 
605 Mission St., Santa Cruz, 
CA 95060, (408) 427-4366. 


Reprinted from DIGITAL REVIEW February 19, 1990 
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MultiNet - Destined 

To Be The New Standard. xS- A 

After your 30-day free trial of TGV's 

MuluNet ''‘Software, you'll be converted - 

just like the other VAX'® managers who are 

enjoying MultiNet 's unchallenged performance, lower 

maintenance costs, and simplified network management. 


Superior Support and Maintenance. TGV provides 
support beyond that of the typical software company. 

Our support staff provides assistance in configuring mixed 
environments and diagnosing problems in local and wide 
area networks. Superior support that is unparalleled in the 
industry - as a result, many of our customers have offered 
to act as references. 


Effortless- Installation. Installation is simple. We utilize 
VMSINSIAL. And our documentation follows the DEC® 
format. Our evaluation kit contains an installation tape 
and reference guide that leads you through 7 easy steps 
to complete installation and configuration of the industry’’ 
fastest TCP/IP. 


Quality No-Risk Network Solution. MultiNet comes 
with a special kind of guarantee - the guarantee of a 
product implemented by the same experts who delivered 

the first TCP/1 P for VMS';’ the first VMS/NFS 
Server, and the world's first and only 

| .jF @|ip||k guaranteed quality means lower 
w maintenance requirements. That 

means lower maintenance fees - 
as much as 50% lower maintenance 
than what you're paying now - 
a win-win situation. 


Sound incredible? Call us for references and your FREE. 
NO-RISK 30-day MultiNet evaluation kit. 


Trade-In Offer. Apply up to 100% of the value* of your 
current board or host-based TCP/IP toward your purchase 
of MultiNet software. So you can enjoy up to 6 months 
of free support with your standard MultiNet software 
maintenance agreement?* 


Destined To Be The New Standard, 


MultiNet Ikertx fee "If VwirTGV annual support agreement is signed within <>° days after the pun hose of MuhiNcl. an additional W da vs will he added u* the standard *1 days which are included with every new kense 
- a total id h me mths ■ if free supp«irt TGV and MulliNel air trademarks of TGV. In* VAX and VMS arr registered imlcmirks Digital Fquipmem ( orporatu m 
TGV. Inc . ti}\ Mission Si . Santa Gnu. CA VS060 Tdt-HIM) ti’-t.toh FAXt-tOK> li’-t.kn ©IVK) TGV, Inc 
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MultiNet 

The Multi-protocol Networking Environment 


z 5L 

IGV 


Overview 

MultiNet is a high-performance VAX/VMS multi-protocol networking 
environment. This environment enables the interconnection of VAX/ 
VMS computers to other systems operating the TCP/IP, CHAOSnet, 
or Xerox PUP protocol suites. MultiNet supports the entire family of 
TCP/IP (Transmission Control Protocol/Internet Protocol) services. 

MultiNet utilizes state-of-the-art network technology— 4. 3BSD 
networking software running in the VAX/VMS kernel environment, 
communicating directly with the user process via a $QIO interface, 
and directly with VMS device drivers at the kernel level. MultiNet 
delivers maximum application-to-application performance through its 
implementation of light-weight process threads in the network kernel. 

Installation and configuration of MultiNet has been designed to be 
simple and straightforward for both the experienced and the novice 
system manager: 

• MultiNet contains all the tools for any configuration from an 
end-node system to a fully functional gateway with multiple 
interfaces and routing protocols. 

• MultiNet installs quickly with the VAX/VMS VMSINSTAL utility. 

• MultiNet configures easily to your network environment and 
generates ali configuration files and the startup command 
procedure. 

• MultiNet allows the system manager to examine the state of 
the network, and examine and modify the configuration without 
rebooting. 

• MultiNet includes VMS-style interfaces with DCL commands, 
VMS HELP library entries, and clear, logical prompts for all 
applications and configuration management utilities. 

Services 

MultiNet's Master Server process is responsible for performing or 
invoking services for inbound connections. Many services normally 
performed in separate processes (e.g., BIND. GATED, SNMP) under 
other implementations are performed quickly and efficiently by the 
Master Server itself. Using the MultiNet Server Configuration Utility, 
the system manager can enable, disable, and add new services. The 
Master Server can also restrict IP host and network access: keep an 
audit trail of all connections; and log times, name and addresses, and 
services requested— all on a per-service basis. MultiNet services 
include the following and are all standard to the product: 

• Domain Name System 

MultiNet includes version 4.8.1 of the Berkeley Internet Name 
Daemon (BIND) to provide Domain Name System (DNS) support. 
The MultiNet NSLOOKUP utility facilitates system tracking and 
debugging configuration problems. 

• TELNET 

The TELNET network virtual terminal utility provides transparent 
access between your machine and any other node on the IP 
network. MultiNet has no architectural limit on the number of 
incoming TELNET sessions, and only requires approximately 500 
bytes of memory per connection, making MultiNet ideally 
suited for terminal-server applications with hundreds of incoming 
sessions per machine. MultiNet's TELNET client supports the 


TN3270 protocol, allowing VMS users to access IBM mainframes 
as a 3270 block mode terminal. 

• DECwindows 

MultiNet's DECwindows support provides users the ability to 
run DECwindows applications over TCP/IP in addition to DECnet. 

• FTP 

The File Transfer Protocol utility transfers files between computers 
on an IP network. MultiNet supports two noteworthy exten- 
sions to the standard File Transfer Protocol specification: automatic 
negotiation of a mode providing efficient transparent transfer of 
any FILES-11 file (e.g., ISAM-indexed files) between VMS sys- 
tems; and the use of Lempel-Ziv data compression, which can 
reduce network traffic and effectively increase the speed of slow 
lines by 30-100% (typically 60%). The MultiNet FTP Server uses 
the standard VMS LOGINOUT utility for account validation and 
setup, thus fully supporting all related VMS security features. 

• SMTP 

The Simple Mail Transfer Protocol allows users to send and 
receive electronic mail over an IP network. Access to the 
MultiNet mail system is provided by both the standard VMS 
MAIL utility and the MM mail user interface. 

• MM 

The MM utility provides an alternative to VMS MAIL for electronic 
mail users. MM offers several useful features not available under 
VMS MAIL including: the ability to save and restore messages 
before sending them; the ability to create user-defined headers; 
and a sophisticated message filing and manipulation scheme. MM 
can be used to send both SMTP and DECnet mail. Additionally, the 
MM utility can be used to send mail via the PMDF electronic mail 
gateway system available from Innosoft International, Inc. 

• LPR/LPD 

The LPD protocol client and server allows MultiNet users to 
access printers on remote UNIX computers and vice versa The 
LPD server makes VMS printer queues appear to remote UNIX 
users as local printers. The LPD client runs as a VMS print sym- 
biont using the native VMS PRINT command to print files. 

• BSD "r" Services 

MultiNet includes the popular UNIX V services RSHELL, 

REXEC, RCP, RLOGIN, and RMT. 

• TALK 

The MultiNet TALK utility is a VMS PHONE-like utility which 
allows users to conduct on-line, interactive conversations with 
other users. Like VMS PHONE, TALK provides a split-window 
screen, with one window displaying text one user types, and the 
second displaying text the respondent types For maximum 
interoperability, both the 4.2BSD ‘Old Talk’ and 4.3BSD "New Talk’ 
protocols are supported. 

• GATED 

MultiNet provides support for the EGP (RFC91 1), RIP (RFC- 
1058), and HELLO routing protocols, using GATED Version 1.9 

• SNMP 

A Simple Network Management Protocol agent is included in 
MultiNet, allowing network managers to query such information 
as interface status, protocol statistics, and routing information. 
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• DECnet Protocol Layering 

In addition to sharing a DEC Ethernet controller side-by-side 
with DECnet, MultiNet allows layering of the IP and DECnet 
protocol stacks, DECnet-over-IP allows the system manager 
to configure a point-to-point DECnet circuit between any two 
MultiNet machines across an arbitrary.lP network, IP- 
over-DECnet allows the system manager to configure a 
point-to-point IP connection between any two MultiNet 
machines across an arbitrary DECnet network. These 
features are ideal for expanding connectivity to include both 
protocol families across a connection which only supports 
one protocol family. 

Diagnostic Tools 

The MultiNet PING, TRACEROUTE, and TCPDUMP utilities turn 
every VAX on your network into a network analyzer, PING mea- 
sures the quality of a network connection. TRACEROUTE is used 
to trace the path of an IP datagram through your network to a 
specified destination. TCPDUMP is used to debug LAN problems 
by capturing, formatting, and displaying Ethernet datagrams. 

Custom Applications 

MultiNet includes a 4,3BSD-compatible socket library as well as a 
$QIO interface which allows users to develop custom applications. 

Software Requirements 

VAX/VMS V4.5 or greater. Uses spinlock synchronization to sup- 
port Symmetrical Multi-Processing (SMP) under VMS version V5. 

Supported Configurations 

Digital Equipment Corporation's VAX and MicroVAX computers in 
any valid VMS configuration. 

Supported Network Interfaces 

Ethernet Interfaces 

• All DEC Ethernet controllers currently supported by DEC; 
multiplexing features enable sharing with other protocols — 
DECnet. LAT. and Local Area VAXclustering. 

• CMC's ENP family of Ethernet controllers 

• Excelan's EXOS UNIBUS and Q-bus controllers 

• Interlan's NI1010 Ethernet controller 

• 3-Com's Ethernet controller 


DDN/ARPAnet Interfaces 

0 ACC's LH-DH ARPAnet controller 

• ACC's ACP-5250 and ACP-6250 X 25 controllers, may be 
used to connect systems to the Defense Data Network PSNs 

• IMP 1 1 -A ARPAnet controller 

WAN Interfaces 

• ACC's ACP-5100 and ACP-6100 HDLC T1 controllers 

• DEC'S DMR-11, DMC-11, and DMV-11 DDCMP 

• SLIP (Serial Line IP) using any VMS-supported terminal 
multiplexer 

Other LAN Interfaces 

• Proteon's proNET-10 and proNET-80 Token-Ring controller 

• NSC's PI13/14 Hyperchannel controller 

• Symbolics' CHAOSnet 4-Megabit controller 

Optional Software 

NFS Client for MultiNet 

NFS Server for MultiNet (includes support for PC-NFS) 

Product Packaging 

MultiNet is distributed on a 1600 BPI magnetic tape or TK50 
streaming cassette tape. Included with MultiNet software are 
the manuals; Introduction to MultiNet, MultiNet Installation Guide, 
MultiNet System Administrators' Guide, MultiNet Users' Guide, 
MultiNet Programmers' Reference Manual, and optionally the 
MultiNet NFS Server System Administrators' Guide and MultiNet 
NFS Client System Administrators' Guide. 

Product Support 

Product support is provided for ninety (90) days with MultiNet 
which includes new releases, documentation, telephone consulta- 
tion, and remote diagnosis. Support can be extended to an annua! 
basis with a software maintenance agreement. Contact TGV, Inc. 
for further information. 


• Xerox's 3-Megabit Ethernet controller 



TGV, Incorporated 603 Mission Street (408)427-4366 

(800) TCV-3440 Santa Cruz, CA 95060 FAX (408) 427-4365 


MultiNet is a trademark ol SRI Inicrnaiional and nl TGV, Inc VAX VMS. MicroVAX, DEC DECnet. and DECwmdows are Irademarks of Digital Equipment Corporation UNIX is a irademark of 
AT&T Symbolics and CHAOSnet are trademarks nl Symbolics Inc Xerox and PUP arc irademarks of Xerox Corporation ACC is a registered trademark of Advanced Computer Communications 
ENP is a trademark of Communications Machinery Corporation Exceian and EXOS are registered trademarks of Novell. Inc 4 28SD and 4 3BSO are trademarks ol the Regents of the University 
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MultiNet NFS Client & NFS Server 
for VMS 



Overview 

MultiNet is the first VAX/VMS networking environment to offer both NFS Client and NFS Server for VMS. These features enable the 
complete interconnection of VAX/VMS systems to any other system which supports NFS. 


NFS Client 

The MultiNet NFS Client allows VMS applications to transpar- 
ently access files stored on NFS servers. The NFS Client can 
remote mount file systems on ANY system having an NFS server. 

The NFS Client device driver provides a standard file system 
interface and is called automatically by the normal VMS Record 
Management Services (RMS). 

Remote NFS servers supporting full UNIX (NFS) file system semantics 
appear to VAX/VMS systems as fully-functional Files- 1 1 ODS-2 file 
systems. This includes support for multiple file versions and arbitrary 
VMS (RMS) file attributes. Files created on the server system appear 
as Stream_LF files to the local VAX/VMS system. Text files created by 
the local VAX/VMS system appear as normal 'Stream' files on the 
server and can, therefore, be shared with applications running on 
the NFS server and other (including NON-VMS) NFS clients. Other 
VAX/VMS file types are stored on the NFS server as "raw" VMS data 
blocks (as produced on the VMS system) plus information about the 
VMS (RMS) file attributes. This permits other VAX/VMS clients to 
share these files on the NFS server and non-VMS systems to 
access the data, provided the non-VMS systems are capable of 
interpreting the ’raw" VMS data blocks. 

On systems not supporting full UNIX (NFS) file system semantics, the 
local VAX/VMS system sees a restricted file system, which does not 
support multiple file versions or arbitrary VMS (RMS) file attributes. All 
remote files appear as VAX/VMS Stream_lF files, which permits the 
sharing of text files between systems. 

NFS Server 

The MultiNet NFS Server is a high-performance kernel imple- 
mentation of NFS for VMS. The NFS Server maps the complete 
UNIX file system semantics onto the VMS file system, including 
symbolic and hard links and device files, making a VMS file system 
look exactly like a UNIX file system. When accessed from an NFS 
Client, all VMS text files are type-converted to look like UNIX 
stream files for maximum interoperability. The NFS Server uses a 
file and directory cache between the file system and the network, to 
mask VMS bottlenecks from the requesting UNIX machine. The 
NFS Server uses a proprietary XDR serializer to move data 
directly between the file system cache and the network buffers. By 
default, the cache functions as a write-through cache, but can be 
configured as a write-back cache to increase performance. 


The NFS Server can export all Files-1 1 ODS-2 VMS volumes, 
including shadow sets, bound volumes, and DFS-served disks. 

The NFS Server distribution also includes a PC-NFS authentica- 
tion and print server (PCNFSD). It allows IBM PCs and compatibles 
running NFS client software to access NFS served filesystems as 
though they are local DOS disk drives. PCNFSD supports printing 
from PC clients to VMS print queues. 

Software Requirements 

MultiNet V2.2 or greater and VAX/VMS V4.5 or greater. Uses 
spinlock synchronization to support Symmetrical Multi-Processing 
(SMP) under VMS version V5. 

Supported Configurations 

Digital Equipment Corporation's VAX and MicroVAX computers in 
any valid VMS and MultiNet configuration. 

Product Packaging 

MultiNet NFS Client and the MultiNet NFS Server are dis- 
tributed on a 1600 BPI magnetic tape or TK50 streaming cassette 
tape as part of the normal MultiNet distribution. No separate 
installation is required. 

Included with the software are the MultiNet NFS Server Adminis- 
trators' Guide and the MultiNet NFS Client Administrators' Guide . 

Product Support 

Product support is provided for ninety (90) days with MultiNet 
which includes new releases, documentation, telephone consul- 
tation. and remote diagnosis. Support can be extended to an 
annual basis with a software maintenance agreement. Contact 
TGV, Inc. for further information. 






TGV, Incorporated 603 Mission Street (408) 427-4366 

(800) TGV-3440 Santa Cruz, CA 95060 FAX (408) 427-4365 

MultiNet 'S a trademark of SRI International and nt TGV. Inc VAX VMS. and DEC are trademarks of Digital Equipment Corporaiion 
UNIX is a trademark ol AT&T IBM PC ts a registered trademark ol International Business Machines Corporation 
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NASA 



NSI Operations Center 

Nancy L. Zanlev, Network Operations Analyst 
Sterling Federal Systems. Inc. 


The NASA Science Internet (NSI) Network Operations Staff is responsible for providing 
reliable communication connectivity for the NASA science community. As the NSI user 
community expands, so does the demand for greater interoperability with users and 
resources on other networks (e.g., NSFnet, ESnet), both nationally and internationally. 

Coupled with the science community's demand for greater access to other resources is the 
demand for more reliable communication connectivity. Recognizing this, the NASA 
Science Internet Project Office (NSIPO) expanded its Operations activities. By January 
1990, Network Operations was equipped with a telephone hotline, and its staff was 
expanded to six Network Operations Analysts. These six analysts provide 24-hour-a-dav, 
7-day-a-week coverage to assist site managers with problem determination and resolution. 

The NSI Operations staff monitors network circuits and their associated routers. In most 
instances, NSI Operations diagnoses and repons problems before users realize a problem 
exists. 

Monitoring of the NSI TCP/IP Network is currently being done with Proteon's Overview 
monitoring system (see photo). The Overview monitoring system displays a map of the 
NSI network utilizing various colors to indicate the conditions of the components being 
monitored. Each node or site is polled via the Simple Network Monitoring Protocol 
(SNMP). If a circuit goes down. Overview alerts the Network Operations staff with an 
audible alarm and changes the color of the component. When an alert is received. Network 
Operations personnel immediately: 

a) Verify and diagnose the problem 

b) Coordinate repair with other networking service groups 

c) Track problems, and 

d) Document problem and resolution into a trouble ticket data base. 

NSI Operations offers the NSI science community reliable connectivity by exercising 
prompt assessment and resolution of network problems. 



NSI Site Acronym List 


ARCl Ames Research Center, Moffett Field, CA (router #1) 

ARC2 Ames Research Center, Moffett Field, CA (router #2) 

ASF Alaska S AR Facility/University of Alaska Geophysical Institute 
AUS Australian Academic Research Network 
BBSO Big Bear Solar Observatory, Big Bear City, CA 
CGBE Capital Gallery Building, East Wing, Washington, D.C. 

CrW Carnegie Institution of Washington, Washington, D.C. 

CTIO Cent) Tololo Inter- American Observatory, Chile 

DFRF Ames-Dryden Flight Research Facility, Edwards AFB, CA 
E-1PSP Exterior-Packet Switching Processor Gateway to NSFNET 

EAST Interoperability Gateway 

ESI Astrophysics Data System, Ellery Systems Inc., Boulder, CO 
FA Ford Aerospace, ST DADS Program, Seabrook, MD 

GCGO Gilmore Creek Geophysical Observatory, Alaska 
GISS Goddard Institute for Space Studies, New York, NY 
GSFC1 Goddard Space Right Center, Greenbelt, MD (router #1) 

GSFC2 Goddard Space Flight Center, Greenbelt, MD (router #2) 

GSFC3 Goddard Space Flight Center, Greenbelt, MD (router #3) 

GSFC4 Goddard Space Flight Center, Greenbelt, MD (router #4) 

HAYSTK Haystack Observatory, Westford, MA 
HQ NASA Headquarters, Washington, D.C. 

ICOT Institute for New Generation Computer Technology, Japan 

I STS Institute for Space and Terrestrial Science, York University, Ontario, Canada 

JPL Jet Propulsion Laboratory, Pasadena, CA 

JSC Johnson Space Center, Houston, TX 

KSC Kennedy Space Center, Cape Canaveral, FL 

KSU Kansas State University, Manhattan, KS 

LERC Lewis Research Center, Cleveland, OH 

LPARL Lockheed Palo Alto Research Laboratory, Palo Alto, CA 

MB BBN Mailbridge to MILNET 
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MSFC Marshall Space Flight Center, Huntsville, AL 

MTC Solar Max Mission, Maryland Trade Center, MD 

NCAP24 Encapsulation for AREA 24, ARC, Moffett Field, CA 

NCAP56 Encapsulation for AREA 56, UARS Project, GSFC, Greenbelt, MD 

NC AR National Center for Atmospheric Research, Boulder, CO 

NGS National Geodetic Survey, Rockville, MD 

NZ University of Waikato, New Zealand 

RICE Sesquinet, Rice University, Houston, TX 

SAO Smithsonian Astrophysical Observatory, Cambridge, MA 

SRA Science Research Associates, Glastonbury, CT 

SSC Stennis Space Center, MS 

STIF NASA Scientific and Technical Information Facility, Linthicum, MD 

STSCI Space Telescope Science Institute, Baltimore, MD 

STX ST Systems Corp, Lanham, MD 

SWRI Southwest Research Institute, San Antonio, TX 

UAZ University of Arizona, Tucson, AZ 

UHI University of Hawaii, Honolulu, HI 

UMD SURAnet, University of Maryland, College Park, MD 

UMT University of Montana, Missoula, MT 

USF University of South Florida, St. Petersburg, FL 

USNO United States Naval Observatory, Washington, D.C. 

WFF Wallops Right Facility, Wallops Island, VA 

WWB National Oceanographic and Atmospheric Administration, World Weather Building, 
Camp Springs, MD 
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NSI NOC’s most frequently asked questions. 



Q. What does NSI NOC mean? 

A. NASA Science Internets’ Network Operations Center. 


Q. What does NSI NOC do? 

A. The NSI network operations staff monitors the NASA Science Internet. 


Q. Does NSI NOC perform other duties besides monitoring the NASA 
Science Internet? 

A. Yes, we are also site contacts for other NOCs. 



NOC Questions, continued 



I 



o 

o 



Q. What hours during the day can NSI NOC be reached? 

A. 24 hours a day, 7 days a week. 

Q. Who do I contact when I'm experiencing networking problems? 

A. If you are unable to solve problem through your local site manager, 
call NSI NOC directly at 415 604-3655. 
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F. NSI White Pages Project 


PRECEDING PAGE BLANK NOT FILMED 
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John Ytn, Comimtmcatsom and Nttxseric Dcvabpmmt Branch. EDN, M/5: 2JJ-I5 



• An international standard for a globally distributed 
directory. 

• Provides basic addressing information. 

• Provides detailed information on countries, 
organizations, people, and resources (e.g., where 
printers are). 

• Present pilot project able to access information in 14 
countries. 


It Jm Ym. and NaOaork Onfapm Branch. EDN. MJ& 2JJ-1S 


NASA 


Ames R&s&mzh Cotter 
Moffsit Field. CA * 4035 
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[ohm Fw, ComxnaivcatiDKS end Natm&k CkrcskfsmeM Brands, EDN, M/S: 233-1S 






Advantages of X.500 


The first standardized inter-organization directory 
service. 

Fast becoming a world-wide standard. Pilot project in 
use in 14 countries. 

The only way to access extensive, distributed, global 
information. Other services presently available offer 
only limited information. 


t. Gmrrmnusmvai and Sctssork Dm lofm u Ht Brmck. £DN, M/S. 2JJ-1J 


NASA 


Ama Rooock Center 
Moffett Field, CA 94035 



(Screen Directory) 3S Pod. 


Uses the X-windows system. Simple point and click 
interface makes it user friendly. Accessible to novice 
users. 

Screen oriented interface with the same functionality 


Dish A powerful tool enabling advanced users to access 

extensive information and customize their queries. 

Fred Uses a command line. Specializes in email and 

(FRont-End to Dish) other addressing information. A user friendly 
front-end to dish. 


Xwp 
(White Pages 
interface for 
X.500 System) 


X-windows interface that supports user friendly 
naming. 


John Ym. GsKmawCBtaws ararf htettsori Decdupmam Br&ek, EDN. M/S: 2 33-13 


NASA 


Amm Research. Center 
Moffett Field. CA 94035 
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immediate Goals 


Provide an operational X.500 backbone for NASA 
Science Network users. 

Integrate non-Unix based User Agents. 
Macintosh, PC, VAX/VMS, IBM Profs. 

Establish X.500 access points and provide access 
control lists where appropriate. 


r. EON. MfS: 213- IS 


WASA 


Amts Rastarck Center 
Moffett Field, CA 94015 



» A GOSIP requirement. 


• Access more vital and detailed information. 

X.500 users will be able to access information on 
application processes, entities, and devices. 

• Integrate with non-Science Network X.500 directory 
servers. 


i. Cammumtatmm end Network DemioqmBns Bnmck. EDN, MJS: 213-15 


NASA 


Ames Research Center 
Moffett Field, CA 94035 
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(\IASA 

National Aeronautics and 
Space Administration 

Ames Research Center 


N 91-27 040 


NASA 

Science 

Internet 



What is the NASA Science Internet? 



The NASA Science Internet, NSI, was 
established, in 1987 to provide NASA’s 
Office of Space Science and 
Applications (OSSA) missions with 
transparent wide-area data connectivity 
to NASA's researchers, computational 
resources, and databases. 

The NSI Office at NASA/Ames 
Research Center has the lead 
responsibility for implementing a total, 
open networking program to serve the 
OSSA community. NSI is a full- 
service communications provider whose 
services include science network 
planning, network engineering, 
applications development, network 
operations, and network information 
center/user support services. 


-NSI Network Services 
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NSI's mission is to provide reliable high- 
speed communications to the NASA science 
community. To this end, the NSI Office 
manages and operates the NASA Science 
Internet, a multiprotocol network 
currently supporting both DECnet and 
TCP/IP protocols. NSI utilizes state-of- 
the-art network technology to meet its 
customers' requirements. 

The NASA Science Internet interconnects 
with other national networks including the 
National Science Foundation's NSFNET, the 
Department of Energy's ESnet, and the 
Department of Defense's MILNET. NSI also 
has international connections to Japan, 
Australia, New Zealand, Chile, and several 
European countries. 


NSI cooperates with other government 
agencies as well as academic and 
commercial organizations to implement 
networking technologies which foster 
interoperability, improve reliability and 
performance, increase security and 
control, and expedite migration to the OS1 
protocols. 

NSI will be a major participant in the 
establishment of a high-speed National 
Research and Education Network (NREN). 


ORIGINAL PAGE IS 

OF POOR QUALITY 
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Who does N S I support? 

NS! supports the NASA Science community 
which consists of more than 12,000 Office 
of Space Science & Applications (OSSA) 
scientists, researchers, engineers, and 

administrators around the world. 

NSl's circuits are provided primarily by 
PSCN. It also utilizes other national or 
international science networking 
providers. 

NSl's personnel is noted worldwide for its 
networking expertise, and its highly 
modern operation and control center 
facilities assure leading-edge technology in 
network monitoring and problem control. 


What are NSl’s Service Levels ? 


NSl's basic service provides an open, 
secure, shared network to assure mission 
success. This service includes connectivity 
for file transfer, electronic mail, and 
remote logon. Basic service supports both 
TCP/IP and DECnet, and includes open 
connectivity within the United States as 
well as with international NASA 
collaborators. Sasic Service is provided at 
no charge to authorized users by OSSA's 
Communications and Information Systems 
Division. 

Custom service includes high-speed 
dedicated lines in addition to the basic 
services. Custom service requirements are 
engineered and costed on a case-by-case 
basis. 


NSI provides an open, secure, shared 
network to assure the success of its users' 
missions by: 

• supporting geographically distributed users 

• accommodating advanced applications 

• providing reliable and robust access to remote 
facilities 

• integrating users into the overall network 
environment, and 

• supporting high-performance access to the 
science community 


How do customers connect with NSI? 

Customers contact the appropriate MSS 
Office Customer Service Representative 
{see back page for details) to describe 
their requirements. The NSS Office then 
obtains program authorization and relevant 
accounting information. When that is 
complete, NSI implements the required 
service and monitors performance. 

Customer Service Representatives provide 
continual feedback on the status of the 
customer's request during this process. 

After implementation, the Network 
Information Center, located at the Goddard 
Space Flight Center, will provide 
information about all aspects of the NSI 
program, such as mail, specialized 
applications, data bases, and white and 
yellow pages. 
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What does NSI support include? 


• Requirement® management 
which includes documentation, 
tracking, and reporting from 
initiation through service 
implementation. 

• Real-time, off-line help 

on network- and service-related 
questions, and appropriate referral 
to Network Operations Centers 
(NOCs) and Network Information 
Centers (NICs). 


• A 24-hour/7-day Network 
Operations Center 

(NOC) which monitors network 
traffic and assures network 
reliability, performance, and speed. 

® User services 

o Network Information Center 
o Conference support 
o Documentation and tutorials 
o User groups 

• Security coordination 
provides an audit-trail of network 
activity and information on 
security incidents and intrusions. 


For more information 


Customer Service 

NASA Science Internet 

NASA Ames Research Center 

Mail Stop: 233-8 

Moffett Field, CA 94035-1000 

U.S.A. 

Telephone: Facsimile: E-mail Address: 


Domestic: 
1-415-604-5859 
FTS: 464-5859 

I n ls rn align a L. 

01-415-604-5859 


415-604-0063 IP: nsi-nic@nsipo.nasa.gov 

FTS: 464-0063 DECnet: ames::’nsi-nic@nsipo. nasa.gov" 

2481 0::"nsi-nic@nsipo. nasa.gov" 
NASAMAILNSINIC 


National Aeronautics and 
Space Administration 

Am®* Research Center 
Moffett Fieid, California 94035-1000 


NSI2-91 a 
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The NASA Science Internet - An Integrated Approach to Networking 
by Fred Rounds, NSI Project Manager 

An integrated approach to building a networking infrastructure is an absolute 
necessity for meeting the multidisciplinary science networking requirements of the OSSA 
science community. These networking requirements include communications connectivity 
between computational resources, databases, and library systems, as well as to other 
scientists and researchers around the world. 

A consolidated networking approach allows strategic use of the existing science 
networking within the federal government, and it provides networking capability that takes 
into consideration national and international trends towards multivendor and multiprotocol 
service. It also offers a practical vehicle for optimizing costs and maximizing performance. 
Finally, and perhaps most important to the development of high-speed computing, is that 
an integrated network constitutes a focus for phasing to the National Research and 
Education Network (NREN). 

The NASA Science Internet (NSI) program, established in mid 1988, is structured 
to provide just such an integrated network. NSI coordinates and consolidates science user 
requirements for non-mission-critical computer networking. It further designs and 
implements its networks to provide the computer protocols and performances needed by the 
scientists. In the process of consolidating circuits, NSI uses multiprotocol and interprotocol 
networking technology and works to facilitate sharing of applications software and 
services. NSI also coordinates the integration of Code SC information systems as well as 
advanced applications, such as remote visualization, wide-band video, etc., into the 
network. Throughout its operations, NSI is responsible for providing efficient management 
of NASA data communications facilities and for assuring resource control and security. 

The initial step in gaining connectivity to NSI is for potential users to contact NSI's 
Customer Service Representatives. The CSRs gather the user's requirements on Network 
Service R.equest forms; when such requests are validated by NASA Headquarters as 
QSSA-supported projects, the requirements are passed on to NSI Engineers who configure 
the network architecture, acquire and test the circuits, and bring the circuits into full 
connectivity with NSI. 

NSI provides users with full support. NSI's Network Information Center at 
Goddard Space Flight Center plans to provide user support services in the form of White- 
and Yellow-Page Directory Services, a User Help Desk, and periodic NSI User Working 
Group meetings. The Network Operations Center at Ames Research Center monitors NSI 
networks 24 hours a day, 7 days a week. The Operations Center monitors and analyses 
network traffic, manages problems that arise, and handles equipment installation, 
upgrades, and maintenance. 

The integrated networking approach provided by NSI significantly increases 
scientific collaboration. It improves access to large-scale scientific computing, data 
processing tools, mail facilities, and other federal and international networks, and it makes 
more rapid and efficient exchange of scientific data possible. 

NSI2-91c 
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NSI Directed to Continue SPAN'S Functions 
Fred Rounds, NSI Project Manager 

During a series of network management retreats in June and July of 1990, 
representatives from NASA Headquarters Codes O and S agreed on networking roles and 
responsibilities for their respective organizations. The representatives decided, that NSI will 
assume management of both the Space Physics Analysis Network (SPAN) and the NASA 
Science Network (NSN). SPAN is now known as the NSI/DECnet, and NSN is now 
known as the NSI/IP. Some management functions will be distributed between ARC and 
GSFC. NSI at ARC has the lead role for requirements generation and network engineering. 
Pat Gary at GSFC will develop Advanced Applications and the Network Information 
Center. He will also lead NSI User Services, but NSI at Ames will continue to provide 
User Services during the transition. The transition will be made as transparent as possible 
for the users. 

DECnet service will continue, but is now directly managed by NSI at Ames. NSI 
will continue to work closely with routing center managers at other NASA centers, and has 
formed a transition team to address the change in management. An NSI-DECnet working 
group has also been formed as a separate engineering group within NSI to plan the 
transition to Phase V, DECnet’s approach to Open System Integration (OSI). Transition is 
not expected for a year or more due to delays in product releases. For further information 
and details, contact Warren VanCamp, 415-604-4796 

Plans to upgrade speeds in tail circuits and the backbone are underway. The 
proposed baseline service for new connections is up to 56 Kbps; 9.6 Kbps lines will 
gradually be upgraded as requirements dictate. NSI is in the process of consolidating 
protocol traffic, tail circuits, and the backbone. Currently NSI’s backbone is fractional Tl; 
NSI will go to full Tl service as soon as it is feasible. 

NSI2-91d 
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NSI Sponsors Open Forum 

at the American Geophysical Union Conference, Dec. 1990 

Tom Armstrong introduced the first NSI Open Forum at the American Geophysical 
Union last December in San Francisco. Christine Falsetti chaired the session where users 
were encouraged to raise questions about specific issues concerning NSI. Fred Rounds, 
NSI Project Manager, and Warren Van Camp, NSI Engineer, were on hand to answer the 
questions. Some of those questions are highlighted below: 

Question: How will 56 Kbps upgrades be handled? 

Answer All NSI circuits will be reviewed and a determination will be made of 
circuits appropriate for upgrade. A review will then be held with affected users, following 
which upgrades will begin. The proposed schedule for upgrades will be as follows: 15 
circuits in FY 91, 20 circuits in FY 92, and 17 circuits in FY 93. 

Question: Who can users call for networking services? 

Answer: NSI staff is available to answer questions regarding establishing 

connections to NSI. change of service, resource availability, or network problems. 

Network Information Center: 301-286-7251 
Requirements Control Desk: 4 1 5-604-5859 
24 x 7 Operations Desk: 415-604-3655 

Question: How will organizational issues affect science projects such as 

ISTP and UARS? 

Answer: 1 ) ARC will be the focus of the Network Operations Center, providing 24- 

hour-a-day, 7-day-a-week service. 

2) NSI will design circuits to meet requirements using a wider range of 
tools, such as shared networks (NSF, DOE, DARPA), encapsulation, multiprotocol 
routers, and specialized dedicated circuits where needed. 

3) The NSI backbone will be upgraded. 

4) NSI will support DECnet, TCP/IP, and eventually OS I protocols. 

5) NSI will participate in NRJEN as the technology emerges. 

Question: What will the newly formed User Services Group be 

responsible for, and what is it planning to provide for the user 

communities? 

Answer The Network Information Center (NIC) effort will be led from Goddard 
Space Flight Center. The GSFC NIC plans to provide the following services: White/ 
Yellow Pages directory services; user help desk and hotline (in conjunction with the 
Network Operations Center at ARC); user information forums; NSI User Working Group 
coordination and logistics support; regional customer support; user security; information on 
security policies and plans; and "kits" and other security material which will be distributed 
to all users. 
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Question: What is the current status of security on the net? What is being 

done to upgrade the security toolkit? 

Answer: Network security resides primarily with the host This is an essential 

element of open networking. Other measures include continuous network monitoring and 
use of security-oriented tools. 

NSI is preparing a Security Plan and Risk Analysis/Management Plan that 
incorporates both NSI-TCP/BP and NSI-DECnet network protocol security approaches. In 
addition, existing guidelines, tools, and repons are available to assist users in security 
matters. These materials are available for users from the NSI Security Group Leader. Ron 
Tencati, at FTS 888-5223, or 301-286-5223. 


NSI2-91e 
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The MSI User Support Office (MSSUSO) Presents... 

S ASA SCSEMCE INTERNET NETWORK INFORMATION CENTER 
(NSiNfC) ON-LINE SYSTEM 


NSINIC is a menu-driven help facility designed to aid both novice and experienced users of the NASA Science Internet. 
NSINIC includes user guides for general and inter-operating networking functions (e.g., remote logins and file transfers); 
listings of who to call for help at individual NASA centers; and general information about the NSI. Automated utilities within 
NSINIC provide transparent access to on-line help and other systems. Users are encouraged to access the NSINIC on-line 
system and leave comments. 


...from a TCP/IP System: TELNET to DFTNIC.gsfc.nasa.gov (128.183.10.3); username is NSINIC. 

...from a DECnet System: SET HOST to DFTNIC (DECnet address is 6148); username is NSINIC. 

...via Dial-Up Links: Dial the appropriate access number as shown in the following table (all are area code 301), 
then follow the instructions listed below: 


Speed Parity Bit Setting s Telephone 

300-2400 ODD/NONE 8 d/1 s or 7 d/2 s 286-9000 

300-2400 EVEN 7 data/1 stop 286-9500 

9600 NONE 8d/1s or 7d/2s 286-4000 

9600 EVEN 7 data/1 stop 286-4500 


Males 

All these modems automatically set 
themselves for the correct speed. 
Only 8 are available. 

Only 4 are available. 


CALL, DISPLAY, OR MODIFY? 
DIALING nnnnn 
CALL COMPLETE 
Enter username> 

(misc. system messages) 
Local> 

(misc. system messages) 
Username: 


CALL SISC <CR> [NOTE: If dialing from off-GSFC, you will 
see “ENTER NUMBER" instead! 

<CR> <CR> 

(type your name here) <CR> 

C DFTNIC <CR> 

NSINIC <CR> 


...via SorintNet (X.251 Links: Dial your local SprintNet (formerly Telenet) access number, then hit [RETURN] or 
[ENTER] several times until you see the prompt. (Information on local SprintNet access is available from the NSIUSO.) 
NOTE: If you are dialing in to SprintNet, you will need a NASA Packet Switched System (NPSS) DACS userid; contact the 
NSIUSO for more information. 


‘CONNECTION ESTABLISHED* 

(misc. system messages) 

* 

ENTER USERID> 

ENTER PASSWORD> 

ENTER SERV1CE> 

(misc. system messages) 
Username: 


C NASA 
<CR> <CR> 

LOGON <CR> 

(your DACS ID) <CR> 
(your DACS p/w) <CR> 
DFTNIC <CR> 

NSINIC <CR> 


Questions and/or comments about the NSINIC may be e-mailed to the account name "NSIHELP" at any of the following: 
DECnet: DFTNIC (6148) TCP/IP: dftnic.gsfc.nasa.gov (128.183.10.3) BITNET: dftbit 

NASA Science Internet User Support Office 
Advanced Data Flow Technology Office, Code 930.4 
NASA Goddard Space Flight Center 
Greenbelt, MD 20771 

301 -28^-7251/951 4 or FTS 888-7251/9514 
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